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ABSTRACT 


This thesis studies and discusses the development of 





the API, called the persistency API, for supporting the 


persistent data sessions. Without persistent session 





support, network applications often need to be restarted 





from the beginning when intermittent physical connection 
loss happens. Application programmers can use the 


persistency API to achieve th service continuity. The 








persistency API provides the interface that allows a 











program to continu retriev data from the point the 
connection is lost after the physical connection is 
restored. The focus of this thesis is to develop a 


generalized persistency API that supports various types of 
applications. This thesis studies the persistent session 
support for two types of transport protocols, TCP and UDP, 
which are used by major network applications. An 


application that performs text file and video file transfer 








is implemented to demonstrate the persistent data transfer 
sessions for TCP and UDP, respectively. The study shows 


that the proposed APIs can support the data transfer 





continuity in the reconnection process. 
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A i INTRODUCTION 


A. PROBLEM STATEMENT 


One of the problems during the Signal operation in 





Thailand is the lack of service continuity of the data 





communication between end users at the application level. 











To complete the mission, the applications need to be fully 


transferred regardless if the state of the physical 





connection is disrupted or not. Currently, an error or the 


loss of the physical connection during the data transfer 





sessions can cause the disruption in the application 
operation. Et requires manual restarting of the 
application. If the physical connection is lost either from 








the system itself or from the interference, it is not easy 





to reconnect at the beginning of the session and retransmit 








the entire data in order to provide the reliable content 
delivery. However, in each Signal operation, such 


applications have to be resubmitted as soon as possible to 





nsure the survivability of the service. To achieve the 








goal of the mission for this case, not only must the 
service survivability be established but the applications 


also need to operate seamlessly in the face of a physical 





connection loss. The interrupt data or the state of the 





connection must be continued from the point it was stopped. 


B. SCOPE AND METHODOLOGY 


This thesis develops an application-level support of 





persistent sessions to various applications. Specifically, 
APIs for general applications using persistent connection 


are designed and implemented. 


The research follows the methodology that can _ be 


conducted as follows. Firstly, the research starts with 





searching for the existing protocol emphasizing File 





Transfer Protocol, Real Time Streaming Protocol, and 
Telnet. The study of these protocols can be background 
knowledge in order to extend this concept for this 
research. The research then goes on specifying each 


protocol parameters and application requirements for both 





user interface and the connection protocols. This area has 





to be studied in depth because the result from development 
for each parameter effects the system. The critical session 
of this research is to design and develop a reconnection 
session using API for each application protocol. The 
development of the API can be done using the supporting 
idea above and this API can be used for generic 


applications in the future. Finally, the testing phase for 





the implemented API needs to be achieved in order to 








guarantee the service for persistent sessions. This testing 





is conducted on a wired environment to reconnect the FTP, 





RTSP or Telnet respectively. If time permits, the migration 














of each protocol will be developed to support this 
research. 

Since Java programming language is popularly used in 
computer network programming and provides a good 
modularity, it was chosen to develop the APIs for this 


thesis. Currently, there are a number of classes in Java 





that can be used to support the reconnection session for 
network protocols. However, each protocol has to be 
written by the programmers on their own to provide the 
reconnection session when it lost. No APIs specific for 
persistent session support are currently available for 


programmers to use directly. This thesis focuses on 
2 


building new APIs that programmers can write applications 
with regardless of the underlying network protocols the 
applications are using. 


The network environment used for this thesis work was 





based on a wired environment. The research was performed on 
an end-to-end user’s connection. The implementation was 


conducted using a connection on the same network and used a 





variety of protocols to transmit the information and test 








the API. A wireless scenario was an additional environment 





tested for mobile device. As a result, this API can be 
extended in its capability to fully support the wireless 


environment. Therefore, both client and server for this 





research was a workstation running a Windows operating 
system. 


The thesis did not consider the following as part of the 





implementation: 








e Security: The security aspect of the development is 
not covered. Even though it will be used for the military 
operations, the initial purpose for this development is to 
achieve the survivability of the service. There is a 
security tunneling design that would be appropriate to 
encapsulate for each session. Future research may be 


necessary for the extension of this work to increase the 





level of security. 


e Scalability: Even though the multitasking approach is 


suitable for designing on the server-side application 





transferring the data to other hosts, this thesis does not 
address the capability to support a large number of users 
that produce heavy traffic as a single server. 

e Speed of recovery: For this thesis work, speed is not 


an important factor of an experiment. The speed of the 


transmission is forced by the physical connection media and 
performance of both the sender and receiver, which are not 


the main factors to be observed. 


Cc. RESEARCH QUESTIONS 


The following questions are considered in this thesis: 
e What are the key components of persistent session 
service? 
e What are the key components that must be implemented 


in preparing API to support application layer needs? 





e How can this API support the reconnection session? 


e What types of applications can benefit most from the 





protocol developed? 





e How can this communication supplement be flexible when 


the availability of the information server varies? 


D. ORGANIZATION 
The covered material is organized into the following 


chapters in order to fulfill the objectives of this thesis. 








Chapter II covers the background and related works that 


provide the introduction to Persistent Data Sessions and 





previous research works. Chapter III refers to the on-going 
Reliable Content Delivery using Persistent Data Sessions 


along with the development of Application Programming 








Interface related to this thesis project. Chapter IV covers 





the design and implementation of the thesis process. It 


describes the software design and programming procedure of 








the prototype in detail. It also mentions how the most 





important features of the API are supported in the 








reconnection state. Chapter V summarizes the testing phases 


of the API development and objects models. Specific 


scenarios are conducted for each protocol appropriately. 


Chapter VI presents the conclusion, recommendation 











Finally, 
and the future work to be continued in the establishment of 
persistent data sessions by extending this thesis work to 








support the wireless environment. 
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II. BACKGROUND AND RELATED WORKS 


This chapter will discuss the general knowledge and 


the previous research regarding persistent data sessions 





that are related to the concept of this thesis work. The 


concept of persistent data sessions and an overview of the 








existing network-continuity protocols that have the 


reconnection characteristics will be introduced separately. 





A. RELIABLE CONTENT DELIVERY WITH PERSISTENT DATA 
SESSIONS 


1. Background 
This section refers to the general idea of persistent 


data sessions which provides reliable content delivery of 





the data communication. According to TCP/IP model, this 





procedure is referred to the process at the application 
layer. Before going into the detail of persistent sessions, 


the term ‘session’ will be described as a fundamental idea 





for this section. A session is either a lasting connection 





using the session layer of a network protocol or a lasting 
connection between a user (or user agent) and a peer, 


typically a server, usually involving the exchange of many 





packets between the user's computer and the server. A 


session is typically implemented as a layer in a network 








protocol [1]. In the case of transport protocols which do 


not implement a formal session layer or where sessions at 





the session layer are generally very short-lived, sessions 
are maintained by a higher level program using a method 
defined in the data being exchanged. 

To get the information from a server, a system may 


issue a “request” packet to the server. If a “reply” packet 


arrives in response, the transferring session will be 








started by using one of the following transport protocols: 

e Transmission Control Protocol (TCP) providing a one- 
to-one connection oriented, reliable communication 
service of the sequence and acknowledgement of packets 
sent and recovery of packets lost during transmission. 

e User Datagram Protocol (UDP) providing one-to-one or 
one-to-many connectionless, unreliable connection 
service which is used when the amount of data to be 
transferred is small, when the overhead of 
establishing a TCP connection is not desired, or when 
the application or upper-layer protocol provide 


reliable delivery. 





Extended from the concept of the term ‘session’, 
persistent data sessions, or persistent connections which 


are sometimes called “keep-alive” connections or 


7 





“connection reuse,” can be used to optimize the way servers 


return content to the client. It is the idea of using the 





transport protocol connection to send and receive multiple 
requests or responses, as opposed to opening a new one for 
every single request or response pair. As proposed, the 
client can send multiple requests on a single connection. 
This capability is negotiated in response to the first 


request on a connection. The server can choose how many 





requests it will allow on a persistent connection and also 








how long to wait for subsequent requests before terminating 





the connection. Most servers will allow you to configure 





these things. 





Ther ar several advantages of using persistent 


connections [2] including: 


e Network friendly. Less network traffic due to fewer 





setting up and tearing down of connections. 


e Reduced latency on subsequent request. Due to 


avoidance of initial protocol handshake 


e Long lasting connections allowing protocols sufficient 








time to determine the congestion state of the network, 





thus to react appropriately. 


B. EXISTING APPROACHES IN PROVIDING PERSISTENT DATA 
SESSIONS 


This section is about the existing protocols related 
to the service continuity characteristic. The concept of 


both kinds of protocol is related to each other but 





different in the level of operation. M-TCP is resided in 





the transport layer which provides the guarant service 
Similar to TCP but has additional features in order to 


achiev th servic continuity. Another protocol called 








PFTP is a little bit different from the first protocol 





because it is developed at the application layer which uses 
TCP as an underlying protocol. The details of each will be 
described following. 
1. Migratory Transmission Control Protocol (M-TCP) 
a. Overview 
This protocol is proposed from the Laboratory for 
Network Centric Computing (Disco Lab) at Rutgers University 


[3]. The concept of this protocol is called service 





continuity. M-TCP is a transport layer protocol for 


building highly available network services by means of 





transparent migration of th server endpoint of a live 
connection between cooperating servers that provide the 


same service. The origin and destination server hosts 





cooperate by transferring supporting state in order to 


accommodate the migrating connection. It is one of the 
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network reconnection solutions to reestablish another 











connection using the point that lost the connection to the 
previous server to try to reconnect to another server for 


retrieving the same information at the point it was lost. 








Therefore, the two servers that serve such clients have to 


have good coordination between each other. 


The client starts a service session by connecting 





to a preferred server, which supplies the addresses of its 





cooperating servers, along with authentication information. 


The client endpoint of a connection can initiate a 





migration by contacting one of the alternate servers. The 





migration trigger may reside with the client or with any of 








the servers. The server endpoint of the connection migrates 
between the cooperating servers, transparent to the client 


application. 


This protocol is compatible with TCP in which the 


client protocol stack can initiate migration of the remote 





end point of live connection to an alternat server. 


Migration is transparent to the client application. M-TCP 





decouples the migration mechanism from migration policy 


that specifies when a connection should migrate. Migration 





may be triggered according to some migration policy under 
conditions like server overload network congestion, the 
loss of physical connection, degradation in performance 
perceived by client, etc. 

b. Goals and Features of M-TCP 

The goal of the M-TCP is to support the 





efficiency of live connections. It also offers a better 
alternative than the simple retransmission to the same 
server, which may be suffering from overload or Denial of 


Service attack, or may be known or maybe not be easily 
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reachable due to congestion, and decouples a given service 


from the unique/fixed identity of its provider. 








This protocol has features as the following. It 


is general and flexible which means that it doesn’t rely on 





knowledge about a given server application or application 








level protocol. It allows fine-ground migration of live 





individual connection, unlike heavyweight process migration 
schemes, and it is symmetric with respect to and decoupled 
from any migration policy 

c. M-TCP Mechanism 

The M-TCP design assumes that the state of the 


server application can be logically split among connections 





by defining a fine-grained state associated with each 


connection. 





The M-TCP service interface can be best described 


as a contract between the server application and the 





transport protocol. According to this contract, the 





application must execute the following actions: (i) export 


a state snapshot at the old server, when it is consistent 





with data sent/received on the connection; (ii) import the 


last state snapshot at the new server after migration, to 








resum service to client. In exchange, the protocol: (1) 





transfers the per-connection state to the new server and 
(ii) synchronizes the per-connection application state with 


the protocol state. 
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z | 
Client 





SYN + MIGR“RE 
(a) 








: Cooperative 
es servers 


Figure 1. Migration mechanism in M-TCP. 

From Figure Tey Connection Cid, initially 
established by client C with server S2, migrates to 
alternate server S2. The migration mechanism of M-TCP 
ensures that the new server resumes service while 
preserving the exactly-once delivery semantics across 
migration, without freezing or otherwise disrupting the 


traffic on the connection. 
need to change. 


A client contacts the 


service 


The client application does not 








connection Cid to a preferred server Sl. 








setup, Sl supplies the addresses. of 
servers, along with migration certificates. 
M-TCP initiates migration of Cid by 





connection to an alternate server S2, 


certificate in a special option. 
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(Figure 


through a 


At the connection 





its cooperating 


The client-side 
a 


opening new 


sending the migration 


l(a)). To 


reincarnate Cid at S2, M-TCP transfers associated state 
(protocol state and the last snapshot) from Sl. 

Depending on the implementation, the state 
transfer can be either (i) lazy (on-demand), i.e., it 


occurs at the time migration is initiated, or (ii) eager, 





i.e., it occurs in anticipation of migration, e.g., when a 
new snapshot is taken. Figure 1 shows the lazy transfer 
version: S2 sends a request (b) to Sl and receives the 


state (c). If the migrating endpoint is reinstated 





successfully at S2, then C and S2 complete the handshake, 


which ends the migration (d). 





Upon accepting the migrated connection, the 


server application at S2 imports the state snapshot. It 





then resumes service using the snapshot as a restart point, 
and performs execution replay for a log-based recovery 


supported by the protocol. The execution replay restores 





the state of the service at the new server and synchronizes 





it with the protocol state. To support the replay, M-TCP 


logs and transfers from Sl data received and acknowledged 





Since the last snapshot. It also transfers unacknowledged 





data sent before the last snapshot, for retransmission from 
S2. 


2. Reliable Content Delivery Using Persistent Data 
Sessions in Highly Mobile Environment 


The work was to develop a client-server file transfer 


application named Partial File Transfer Protocol (PFTP) to 








demonstrate a possible solution to the problem of a lack of 














persistent data sessions in wireless mobile networks and 





LANs. This protocol was developed at the application level 
which used TCP as an underlying protocol. For this purpose, 


a prototype communication protocol between the client and 





the server were designed using Java Technology to achieve 
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dynamic partial file retrieval in the event of connection 
loss. The goal is to produce an application user interface 
that visualizes the partial file retrieval process in real 
time. This is a proof of concept for service continuity 
protocol development. Since it has a limitation in 
transport protocol development, it can support some 
applications that use TCP as an underlying protocol only. 
As a result, the concept of this work is to be extended in 
order to support various applications that use either TCP 
or UDP as an underlying protocol. 
a. PFTP Mechanism 


PFTP is an application layer protocol that is 





based on a client-server communication scheme. For the file 
transfer process, an application layer communication 
protocol must be established. The TCP protocol is the 


underlying protocol for every connection and data transfer 





between the client and server (Figure 2). 


PFTP TCP based PFTP 
Client ——<—<—==)) Server 
Communication protocol 


Figure 2. The communication scheme of PFTP application 








File Request Message 
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This communication protocol is shown in Figure 4 





[4] and starts with the PFTP server running and waiting for 








clients at port 6789. When the user opens the PFTP client 











application, it must choose a PFTP server manually or from 








a list of already existing servers in order to retrieve th 





list of files available for transfer. In the predefined 





server case, an Auto server mode option exists which can be 





selected when the user wants the application to choose a 





predefined PFTP server randomly during either the initial 





available file retrieval or the partial file retrieval 








process after a connection loss. When the file list is 





retrieved, a user selects a file name and the packet size 
and forms a file request packet that is sent to the server. 


The request packet fields are shown in Figure 3. 
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PFTP Client 


Client is running. 
User selects a server to 
rereive the files that are 

available to transfer 


User selects the file 
transfer features. 
Ask for the file. 


connection loss and 
reconnect with server. 


Sets the offset 
and the 
hash value 
in the file request packet 
and ask the file. 


Receive all the 
packets. 
Close the connection 


Send the hash value and 


Send the file list 
Connect to server 


Send the file request 


Sending file packets 
sending file packets 


Connection lost 


Connect to server 


the file Ze 


the partial file reque 


PFTP Server 


Server is running 
Waiting for clients 


Server replies 
sending the 
available file list 


Server check if 

has the file and 

| _™ | compute the file 
hash value. 


Start sending 
the file packets 


Server checks if 
has the file with the 
same hash and 
continue to send 
the rest of the file 
packets. 





Figure 4. The communication protocol of PFTP application 


The server checks if it has the file and, 





does, sends the file size and the hash value of the fil 


back to client. 


data and sends it in packets to the client. 


Then the 


server 
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starts 


5 eae 


Le 





reading the fil 


Le 


If, during the 


packet transmission, a connection failure occurs, the 








client side generates partial-file-request packet, setting 


the offset field value with th next xpected packet 








counter and the hash field value with the file hash 














received at the start of the file transfer. Then the client 








attempts to reconnect with the same server or, if the Auto 
server mode is selected, with the next available PFTP 
server, and when it is connected, sends the prepared 


partial-file-request packet. 


The server that receives the packet, if the 








offset value is greater that zero, checks if it has the 
same file with the same hash value and continues sending 
the remaining data in packets to the client. Each file 


connection loss causes the same partial transfer retrieval 











scheme until the client receives all the file packets and 


both the client- and server-sides close the connection. 
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IIl. API DESIGNS FOR PERSISTENT DATA SESSIONS 


This chapter provides an introduction to the 
background, capability, and purposes of the APIs used for 
this thesis. APIs developed for this thesis to support 


persistent sessions for various applications will be 





presented. 
A. INTRODUCTION TO APPLICATION PROGRAMMING INTERFACE 

ue Introduction 

An Application Programming Interface (API) defines how 
programmers utilize particular computers features. Some 
often used APIs provide programmers with access to display 


system, file systems, database systems, and networking 





systems. The APIs developed in this thesis are designed to 


support a structured approach to network programming. 





Special attention has been paid to the needs of multimedia 





applications and to the future requirements of network 
protocols. After surveying the current approaches, the need 
was observed for an interface that provides ease of use, 


extendibility and portability. An object-oriented method 





that will meet these needs is chosen. 
Currently, application programmers are writing more 
details for underlying functionality and using specific 


code to interface with the network and transport layers 





defined by the OSI model. This requires that programmers 





learn how to communicate with the underlying network. 


Technicalities include opening and closing communication 





channels and manipulating data structures. An example of a 





low level interface used by application programmers is the 





Berkeley Sockets interface which UNIX systems support [5]. 
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Many applications that run over networks contain this 
type of interface or one of equivalent complexity. 


Moreover, the complexity is coupled with redundancy; not 





only must an interface be written for every application, if 


a programmer changes the protocol an application is using, 





the program’s interface to the transport and network layers 
needs to be rewritten. 
This non-portability of applications between network 


and transport layer protocols could be aggravated by the 











availability of new, more intricate network level protocols 





which provide features for multimedia and real-time 





applications. These protocols are designed to support 


resource allocation. They allow applications to specify 





their performance requirements and receive performance 


guarantees. Although the demand for these services has been 





firmly established, easy access to the protocols that 








supply them has not yet been made widely available. With 
such a variety of protocols and the complexity inherent in 


implementing them, it would be efficient to supply 





application programmers with a high-level interface to the 








underlying layers. The need for improvements in system 


software in order to not only support the basic reliable 








protocol but also support real-time and multimedia 
application has been recognized by previous research. For 
these reasons, a generic Application Programmer Interface 
(API) which acts as a level of abstraction between the 
application programmer and the network and transport layer 


protocols ar developed. Figure 5 shows the architecture 





where API abstractly resides within the OSI model. 
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Application Layer 


Transport Layer 


Network Layer 





Data Link Layer 


Figure 5. OSI Model with API 


The following figure is an example of the data flow 
from side to side using API 


application layer. 


support 


starting from the 





RTP Connection 


Figure 6. API support for end-to-end connection 


B. API SUPPORT FOR PERSISTENT DATA SESSIONS 
Ls Practical Consideration 
During a normal network session, servers will usually 
have some time-out value beyond which they will no longer 
maintain an inactive or 





lost connection. 


Proxy servers 
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might make this a higher value since it is likely that the 
client will be making more connections through the same 
server. The use of persistent connections places no 


requirements on the length (or existence) of this time-out 





for either the client or the server. 

When a client or server wishes to time-out, it should 
issue a graceful close on the transport connection. Clients 
and servers should both constantly watch for the other side 


of the transport close, and respond to it appropriately. If 








a client or server does not detect the other side's close 
promptly it could cause unnecessary resource drain on the 
network. 

A client, server, or proxy may close the transport 
connection at any time. For example, a client might have 
started to send a new request at the same time that the 
server has decided to close the “idle" or “lost” 
connection. From the server's point of view the connection 
is being closed while it was idle, but from the client's 
point of view a request is in progress. 

This means that clients, servers, and proxies must be 
able to recover from asynchronous close events. Client 
software should reopen the transport connection and 


retransmit the aborted sequence of requests without user 











interaction so long as the request sequence is idempotent. 
We propose to develop software procedures at the 


application layer and generate APIs for general use. Non- 





idempotent methods or sequences must not be automatically 





retried, although user agents may offer a human operator 
the choice of retrying the request(s). Confirmation by 


user-agent software with semantic understanding of the 








application may substitute for user confirmation. 
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Servers should always respond to at least one request 








per connection, if at all possible. Servers should not 
close a connection in the middle of transmitting a 
response, unless a network or client failure is suspected. 
2. Problem Concern 
From a consideration above, the problem will be mainly 
focused on the lost state. When a physical connection is 
lost, that means the connection has to be reestablished and 


the data has to be retransmitted from the beginning of the 





file. For TCP connection, even though it uses a connection- 
oriented mechanism which controls the content of the data 


to be sent appropriately, it is necessary to make a new 








connection manually for this scenario. The API will help 





the programmers during this session by automatically 
detecting the physical connection and making a new 


connection instead of the client. In case of an unreliable 





connection like UDP, the data is being sent regardless of 
the packet loss. To be a persistent session, the proposed 
API will control the rest of the data in order to achieve 


the virtual reliable protocol as a persistent data session. 





In order to assist users in programming the process of 





reconnection, the procedure of the reconnection phase will 
have to be provided step-by-step. There is no programming 


library that can support all of the steps for the 





reconnection process. This is also applied to the states of 





connectionless session. The lost connection has to _ be 





reestablished in order to complete sending the file to the 
destination. 


As above, the API is another proposed solution for an 





asier reconnection. Such a package can be called to 


manipulate the physical connection instead of doing so 





manually. All the programmers need is to call this package 
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which consists of the related functions to reconnect the 
ongoing session when the physical connection has been lost. 
Therefore, while the data is being transferred to the 
destination, the state of the connection and the critical 
parameters the program is using at that time have to be 
tracked or recorded in order to make a reconnection without 


prompting the user. The following figure is an example of 





the API process for mobility client [6]. This client can be 
both mobility and stationary object. 


Mobility Client API calls 


Mobility Client Events 





Figure 7. API message flows 
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Cc. API DESIGN FOR VARIOUS NETWORK APPLICATIONS 

1. Purpose 

For this thesis project, the APIs are not developed 
for specific applications, but aim to be used by a 
multitude of programs that use either TCP or UDP as an 
underlying protocol. Therefore, the existing socket APIs 


will be used as supporting libraries for the implementation 





of the new API. The development of the software-based 





application will be performed in JAVA technology 
programming. 
2. Area of Research 


Although there are a variety of the applications used 





in today’s networking scope, the underlying protocols of 


such applications are still either TCP or UDP. The API 





will be developed to support the problem mentioned above 


along with the development of the client and the server 








application for a particular scenario. This thesis will 





develop the API to be suitable for various applications 





using TCP or UDP as an underlying protocol. Ideally, it has 





to be developed to be suitable for all applications (e.g. 











FTP, Telnet or UDP-related applications), but for this 











thesis not all applications will be covered because of the 
different characteristics of each application. Each user- 


defined protocol has different states and parameters to be 





reconnected so that the thesis project will be focused on 





the servic continuity based on the popularity of 





applications. The protocols we are researching are File 
Transfer Protocol (FTP), which uses TCP as an underlying 
protocol, and Real Time Protocol (RTP), which uses UDP as 


an underlying protocol. These two applications can be 





instances of the development for transport protocol. 








Certain features of real time applications, such as 
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synchronization, are not currently supported but are 


addressed as areas for further study. 
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project, including the APIs developed for persistent 


session support and the client-server application that 





imp 


IV. DESIGN AND IMPLEMENTATION 


This chapter presents the critical parts of the 

















utilizes the APIs. The details of the API and the GUI 


lementation are discussed. The application-user 





interactions are presented at the end of this chapter. 


A. 


DESIGN 


KA Main System Components 


For the rest of this thesis, we will refer the APIs 


developed in this research to support persistent sessions 


the Persistency API. The application developed for this 


thesis has three major components: the server, the client 





and the persistency APIs. The details of each component are 


discussed below: 


Server - It is the data source in the communication 
and can handle multiple connections as needed. It 
needs to understand two types of requests, which is 


indicated in the initial connection message: the 





connection request and the reconnection request. The 
reconnection request contains more information than 


the first type. Based on the type of request and the 





information associated with it, the server determines 


the starting point of the data to be sent. 














Client - It provides the user interface and interacts 








with the user in order to meet the user requirement. 





It starts the reconnection process in the face of 
physical connection loss by calling the persistency 


APIs without user intervention. Th user needs to 
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input the arguments required for the persistency APIs 


at the initialization. 





e Persistency APIs - It supports the service continuity 
between the server and the client. It is the 


additional API derived from the existing library that 








the client needs to maintain persistent sessions for 
both TCP and UDP connections. It is defined as a class 


and can be called by the client when it detects a 





physical connection failure. 
Persistency API is a major component in the 


application development and is used at the client side. The 








application runs in two modes, TCP and UDP. In the TCP 
mode, it transfers a file from server to client and can 
recover from temporary connection loss. In UDP mode, it 
transfers a video from server to client and can recover 
from temporary connection loss. In video file 


transferring, there are two types of protocols involved for 





the session. Real Time Streaming Protocol (RTSP) and Real 
Time Protocol (RTP). RTSP is used for video control session 
that uses TCP as an underlying protocol. RTP is used for 
retrieving the video packets which is one of UDP 


communications. The development is mainly focusing on the 








RTP session in order to provide the continuity of the 
video. 
a. Graphic User Interface 


Both client and server modules will provide a 





user-friendly interface. In this initial version the user 
interface of the client side will provide three main 


services: 
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Protocol selection for the data transfer 








communication. The user must be able to select one 


of the transport protocols for the data transfer. 





View of the data transfer progress. A progress bar 


with the percentage of the file transfer session 





completed is implemented. 





View of the content of the file for both cases of 
text file and video file at the client side. These 


services are represented as separate panels to the 








user interface frame. Figure 8 shows a primitive 
version of a user interface at the client side. 


For the server side, it is unnecessary to provide 


the user interface. Figure 9 shows an initial version of a 


graphical user interface (GUI) at the server side. The 





important GUI will be provided for the following purposes: 





View of the server operation for the connection 


process. 





View of the server operation during file transfer. 
This application will be provided in a separate 


panel. 
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& Client 


Clientis ready 
Please choose one of the commands atthe command bar 








Figure 8. Preview of the client’s user interface 


& Server Process 


Server is waiting for a clientto establish the connection... 








Figure 9. Preview of the server’s user interface 


2. Software and Development Tool 
The test application and persistency APIs are written 
using the Java programming language. JBuilder9 Java editor 


environment is used to develop the application. For both 
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the server-side and the laptop/desktop client version, the 
Java 2 Standard Edition (J2SE) with the Java Development 
Kit 1.4 (JDK 1.4) is used. Persistency APIs for this 
application are developed based on existing Java libraries. 


The following systems are needed to run the 





application with persistency API support: 





e Server: Windows 98, NT, 2000 or XP operating system 
and a Java Virtual Machine. 
e Client (desktop/laptop): Windows 98, NT, 2000 or XP 


operating system, Java Virtual Machine and the Java 





2 SDK1.4 installed. 





<i Basic API and Program Interactions 


The user must specify the preferred type of transport 





protocol, which is either TCP or UDP, before starting the 








data transfer. For this thesis project, the selected 





transport protocol determines the type of application, file 





or video transfer, the client and the server will perform. 


As indicated in section A.1, selecting TCP will result in 





starting a file transfer application, and selecting UDP 
will result in starting a video transfer program. The 
specification of the type of the protocol must be done at 
the beginning of the execution. 

a. File Transfer 


The file transfer from the server to the client 











results from a client-side user request. The file size of a 


desired file is first transferred to the client so it can 





be used to display the progress bar. The server sends the 





file as a series of packets (arrays of bytes or arrays of 





frame) that the client collects until it receives all the 





content of the file. The client application keeps track of 


the number of packets received. In case of the physical 
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connection failure during the transfer, the persistency 
API, which resides at the client side, is used to reconnect 
until the physical connection is resumed. The new 


connection state is returned to the client, and the client 





continues to retrieve the rest of the packets until the end 
of the file. Thus, the client doesn’t have to restart the 
connection and receive the content of the application from 
the beginning. If the physical connection is lost again, 
the same process will be repeated as before. 

b. Client-server Communication Protocol 

For the file transfer process, an application 
layer communication protocol must be established. The 
following figure shows the abstract of the communication 


protocol with persistency API support: 


Persistency API 





TCP 
Client => server 
UDP 
Figure 10. The communication scheme with persistency API 
support 


The application starts with the server running 
and waiting for the client at either port 5555 for TCP or 
port 9999 for UDP connection. After the user starts the 
client application and makes a selection of the type of 
protocol to be used, the server will respond to the client 


connection request without any user intervention. 
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After an initial connection is established, a 





file size request will be sent followed by the file content 





request from the client to the server. The request packet 


field is shown in Figure 11: 
































Packet 
Request Type Offset ; 
yP Size 
Figure 11. A request message packet 
After receiving the first request from _ the 
client, the server sends the file size in bytes back to the 




















client. Then it waits for the client’s next action. After 





getting the next request, the content of the file will be 





sent as a series of packets to the client. 
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Client 


Client is running and 
waiting for the user's 
action. 


User selects type of 
application for the file 
transfer and ask for a 

file size 


Get a file size and ready 
for the next action. Ask 
for file content from the 

user's action 


Receiving file packets 


Connect to the server 
Ask for file size 


Sending the file size 


Send the file request 


Receiving file packets 


Client sense the 
connection lost and 
forward to the API 

process 


Persistency API 


Sending a series of 
requests until sensing 
the connection 
resumed. Make a 
request to get the partial 
file and return to the 
client 


Close the connection 


Figure 12. 


Server 


Server is running and 
waiting for the client 


Server replies sending 
the file size and waits 
for client's action 


Receive a request 
and ready to 
transfer file 
packets 


Start sending file 
packets 


Close the connection 


Server establish the 
connection. Receive a 
new request and 
continue to send the 
rest of the file as a 
series of packets until 
the end of the file 


Close the connection 





The communication protocol with API support 
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Ty during the transmission, a physical 





connection failure occurs, the client side must detect it 
by using a time-out mechanism. A distinction between the 


packet loss and the physical connection failure can be 





judged by Java application exceptions. After detecting the 
failure, the client will call the persistency API to 
reconnect to the same server. A series of reconnect 
requests will be sent out until a reply from the server is 


heard. After the connection is resumed, information needed 





to reestablish a connection is sent to the server and the 
client’s important parameters are being updated in order to 
continue the session. The client will continue to receive 
the rest of the data after the persistency API call is 
returned. Each physical connection loss causes the same 
partial transfer retrieval scheme to take place until the 


client receives all the data packets and both the client 





and server sides close the connection. 
Cc: Activity Diagram 
Figure 13 shows the activity diagram for API 


support application 
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Start state: Client started Start state: Server started 










open up the}connection} [Read file content] 





Make a connection to the server 





Waiting for a client 


tees 
a= 








[connect tolthe server] 


Persistency API 


Final state: Client closed Final state: Server closed 


Figure 13. The activity diagram for persistency API 


d. Class Diagrams 
The following, Figure 14, shows the relationship 


between the classes for this thesis project: 
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BorderLayout 
Component 
Container 


Dimension 
GridLayout 
image 
LayoutManager 
Toolkit 


BufferedReader 
Bufferedy\riter 

File 

FilelnputStream 
FileNotFoundException 
FileReader 
IOException 
InputStream 
InputStreamReader 
InterruptediOException 
OutputStream 
OutputStream vriter 
PrintStrearm 

Reader 

Meriter 


ConnectException 
DatagramPacket 
DatagramSocket 
InetAddress 
NoRouteToHostException 
ServerSocket 

Socket 

SocketException 
SocketTimeoutException 
Unknow nHostException 









Client 


ConnectionControl 


RTPpacket 
Server 


ServerThread 
VideoStream 





ActionEvent 
ActionListener 
Window dapter 
VVindowEvent 
WindowListener 


ArraylndexOutOfBoundsException 
Character 

Exception 

Integer 
NullPointerException 
NurmberFormatException 
Object 

Runnable 

String 

StringBuffer 

System 

Thread 


icon 
Imagelcon 
JButton 
JFrame 
JLabel 
JMenu 
JMenuBar 


JMenultem 
JOptionPane 
JPanel 
JProgressBar 
JScrollPane 
JText4rea 
Timer 


Figure 14. The class diagram for API support application 
In addition, Appendix B shows the client 
desktop/laptop, the server and the API versions of the 


od 


class diagrams for the content of each class. Appendix B 





also includes the supporting classes for UDP sessions, 
which have RTPpacket and VideoStream classes at the client 
side. 
B. PERSISTENCY API IMPLEMENTATION 

The main purpose of the application developed for this 
thesis is to experiment and validate the persistent session 
support used. The specific API for such support, called 


the persistency API, is used at the client side. An 





instance of this class is one of client object members. 

1. Overview 

The ‘ConnectionControl’ class is created to provide 
persistent session support. It is coded to be an agent for 
executing the reconnection process on behalf of the client. 
This class has to be initialized at the first stage of the 


application execution, after the client object is created. 





It is also created as an object in order to cooperate with 





the client object. Therefore, the client has a particular 


function called fileControl (Client client, int port, String 





host) that initializes the ConnectionControl object. In the 





fileControl(), three parameters are used to initialize the 


persistency API object; client is the client object, port 





the initial communication port between client and server, 
and host the IP address of the server. The command for 
initializing the persistency API object is: 

controlAgent = new ConnectionControl(Client client, 
int port, String host); 

The controlAgent is an instance of the persistency API 


object. It needs to be initialized in order to coordinate 








with the client’s object. For this initialization, there 
are three arguments at the first time of the 


initialization. These two latter arguments have to be set 
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in the initial values and may be updated later on. The 





ConnectionControl class has a critical function for the 
reconnection session called ReconnectProcess(). This 


function tries to connect Lo the server until le 





reestablishes the old session. 


The important variables used in the reconnection 





session are the following: 


e index - The parameter acts as offset of the data 





file sent so far. It is always updated implicitly 
during the data transfer session. It is retrieved 
automatically by the persistency API in order to 


initialize the reestablished session. 





e host The server IP address. 





e port - The communication port for the file 
transfer. It is static for the TCP session but it 
is dynamic for the UDP session. The Java random 


function is used to generate th dynamic port 





number. 





e client Th client object. ConnectionControl 
needs this handle to pass control back to the 


client after connection is reestablished. The 











client will continue the data transfer process. 





e done - It is the logic to control the iteration 
in order to make a new connection to the server. 
It will be set to another value after the 
physical connection is resumed. 
The main function of this persistency API, function 
reconnectProcess(), is being called to do the following: 
e Obtain the type of underlying protocol and the 
offset of the file from the client at the point 


before the connection failure. 
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e Send th new requests to the server until the 





physical connection is recovered. 





The additional functions in this persistency API class 
are supposed to support the reconnection operation. There 


are composed of the following: 





e initialization() - This function initializes the 











critical data members of the class 


e setIndex(int index) - This function sets. the 





offset value of the desired file. It is being 
called during each packet transmission. 

e open() - This function is the first step after 
the resumed connection. It creates the input and 
output streams in order to communicate with the 


server. 


e sendTCPRequest() and sendUDPRequest() - These two 


functions are the final steps of the persistency 


API. The details are discussed in the next 
section. 
22 The Use of Persistency API 





When the client detects the physical connection 





failure via the Exception in Java, it calls the member 
function reconnectProcess() of ConnectionControl: 


controlAgent.reconnectProcess (String) ; 





The argument for this function is a string, used to 





indicate the underlying protocol. It can have the value 
“TER” or “UDP”, depending on the type of transfer 


application that is being used. This argument is important 





to determine the appropriate new request to the server. The 





following is the code segment for the reconnectProcess () 


function: 
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114 public void reconnectProcess (String type) { 














138 while (!done) { 

140 EL 

145 socket = new Socket (host, port); 

152 open (); 

155 client.setParameters (socket, br, bw); 
Aoi if (type.equalsIgnoreCase("TCP")) { 

160 sendTCPRequest () ; 

162 } else { 

164 bry-4 

167 sendUDPRequest () ; 

169 } catch (Exception e) {} 

Lyd } // end if - else 

173 done = true; // set the exit of the loop 
175 } catch (UnknownHostException uhe) { 

179 } catch (IOException ioe) { 

187 } // end try - catch 

191 } //end while 

193 } // end reconnectProcess () 





After being called, the persistency API starts a job 
by sending a series of requests to the server. If there is 
no reply, the new socket, line 145, will not be created and 
yields the result in exception occurrence. In Java, if 
there is an exception occurrence, the appropriate catch 


statement will handle this error. Since it jumps to the 





catch statement, on line 179, due to the socket 
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establishment failure, it assumes no connection is resumed 
and continues the iteration within the while statement, 


line 138 - 191. After the connection is resumed, the 








persistency API continues by opening the new stream between 








the client and the server, in line 152, and then sets the 








important parameters to the client object in order for the 





client to continue the data transfer after the reconnection 





completes. Next, based on the argument passed in the 
function, a corresponding request, in line 160 or 167, is 


sent to the server. After sending a request to get a 





partial file from the server (the appropriate offset has to 





be sent), this persistency API returns to the client. The 





client will continue retrieving the partial date at the 





point it lost the connection. 
For clarification, after establishing a new connection 


with the server (below line 145), the further process in 





which the API supports the recovery of the file transfer 
can be categorized into two groups as follows: 
a. Using Persistency API for TCP 


After the new connection is established, the 





persistency API is trying to make a request to get the 
partial file. Therefore, there are two types of 
applications. In this case, the text file is being 


retrieved. From the code segment shown earlier, if the main 





function of the persistency API, reconnectProcess(), 
receives “TCP” as argument, it will force the Nak’ 


statement to call sendTCPRequest(), on line 160, to get the 





text file and the file transfer session will be continued 





right after this command. The following is the pseudo code 


used for sending the new TCP request to the server: 


238 private void sendTCPRequest() { 
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240 String. textout = "/get ™ ++ index; 


247 client.send(textOut) ; 








249 } // end sendRequest () 


The parameter ‘index’ is already updated so this 


function will use it automatically. It is an offset of the 











desired file where the server should start the transfer in 








the reestablished connection. The function sendTCPRequest () 





uses the client’s existing function to send the request 
after establishing the new connection with the server in 
order to have the client continue the file-retrieve job 
after the control is returned to the client. For the TCP 


case, API returns to the client immediately after sending 





the new request. It assumes that the time of returning to 











the client is faster than the period of the request, which 


is sent to the client combined with the period packets that 





travel from the server to the client. The service continues 
from the point it returns and the client continues to 


receive the rest of the file. 





b. Using Persistency API for UDP 
For the case that reconnectProcess() function 


gets “UDP” as an argument from the client, the ‘if’ 





statement of line 157 will evaluate the logic to false and 











senduDPRequest () on line 167 will be called. 


sendUDPRequest() is the function needed to send the new 





request for UDP session. The following is the code segment 


used for sending the new UDP request to the server: 





256 private void sendUDPRequest() throws Exception { 


262 int newRTPPort = client.randomRTPPort(); 
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267 RTPsocket = new DatagramSocket (newRTPPort) ; 

269 client.setRTPSocket (RTPsocket) ; 

270 client.setRandomRTPPort (newRTPPort); 

273 elient.send ("/Sétup-" + andex "I 
newRTPPort); 

274 client.send RTSP request ("PLAY") ; 

278 client.timer.start(); // continue the timer 





after sending the new request 





282 } // end sendUDPRequest () 


Line 262 generates a new RTP port for receiving 


the partial video file from the server. In order to avoid 








the packets from different sessions colliding at the same 
port, a random function is used to generate a new port 
number. The new RTP socket using the new RTP port needs to 


be assigned to the client object in order to achieve 





service continuity because the control will return to the 





client object after a new connection to the server is 
established. 

The parameter ‘index’ is also an offset of the 
desired file and already updated. Java timer class, which 
is used control the file transfer of the video packets, is 
stopped when the connection failure occurred. Thus, this 
function needs to be reactivated after the connection is 
resumed for the next video packets transfer session. AS a 


result, it has to be called again after the connection is 





resumed. After the new request from the API has been sent, 





the API returns the functionality back to the client by 


using the start() method, line 278 of ReconnectProcess(), 
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in which the Java timer is reactivated. The service 
continues from the point it returns and the client 
continues to receive the rest of the file. 
C.. APPLICATION USAGE GUIDE 

1. Client 





The client starts the application by waiting for 


actions from the user. The user must select one of the 


options from the drop down menu as shown in Figure 15. 


& Client 


Get Size 
Get File TCP PERSISTENT 


Figure 15. Client’s selection panel 





After the button connect is pressed after choosing the 
selection, the client program automatically connects to the 


server. The client first sends the file size request. After 








getting the file size, another panel will show up and wait 





for the user’s next actions to retrieve the file. 


After the user presses the “Get Data” button for TCP 





connection or the “Play” button for UDP connection, the 
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client starts to receive the file packets from the server 
and displays the content on the panel until the end of the 
file. Figures 16 and 17 show the preview of the second 


panel for TCP and UDP respectively. 


& Client 





Figure 16. Client’s second panel for TCP session 
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Figure 17. 


The following figures show the second panels 


2B Client UDP Process 





Client’s second panel for UDP session 


retrieving the data from the server. 


& Client 
== Verbose logging started: 9/22/2004 10:29:07 Build type: SHI 


UNICODE 2.00.2600.1106 Calling process: CAWINDOWSiSystern 


32\msiexec.exe === 
MSI (c) (64:F 0): Resetting cached policy values 
MSI (c) (64:F0): Machine policy value 'Debug'is 0 
MSI (c) (64:F 0): ****** RunEngine: 
=r Product: CAWVINDOWS\Downloaded Installations\DAE 
MON Tools 3.47\idaemon.msi 
are Action: 
wees CommandLine: 
MSI (c) (64:F0): Machine policy value 'DisableUserinstalls' is 0 


MSI (c) (64:F0): SOFTWARE RESTRICTION POLICY: Verifying pack 
age --> 'CAWINDOWS\Downloaded InstallationsiDAEMON Tools 3 
47\daemon.msi' against software restriction policy 

MSI (c) (64:F 0): Note: 1: 2262 2: ODigitalSignature 3: -2147287038 


MSI (c) (64:F 0): SOFTWARE RESTRICTION POLICY: CAWINDOWS) 
\Downloaded InstallationsiDAEMON Tools 3.47\daemon.msi is no 





while 


Figure 18. Client’s second panel during TCP transmission 
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& Client UDP Process 





| pas | cose WO 








Figure 19. Client’s second panel during UDP transmission 


If any connection failure occurs, the second panels 
will be paused automatically and the reconnection process 


is undertaken without any user interaction. When the 








connection is reestablished, this panel resumes showing the 





content of the file from the point it paused. 

2. Server 

The server starts the application by waiting for the 
client to connect to it. After establishing the connection, 
a server thread is created to handle the transfer session 
with the client. The main server process, in the mean time, 


can accept other client connections (maximum number of 





clients is 30). The following figures indicate the server 





process: 
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New connection is established! 


Figure 20. Information message from the server 





f& Server Process 


Server is waiting for a client to establish the connection... 


Server accepted 
hread #1 created! 


Server is waiting for a client to establish the connection... 





Figure 21. The server process 


After being connected, another information panel is 
popped up in order to show the process of the transmission. 
These panels are displayed and updated throughout the 


process until the end of the file. The following figures 





show the transmission process using TCP and UDP as an 


underlying protocol respectively: 
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g& TCP Counter 


Character # 5671, s is sent 





Figure 22. The server’s transmission process for TCP session 


g& UDP Counter = |O] x| 





Send frame # 24 


Figure 23. The server’s transmission process for UDP session 
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Vv. TESTING 


This chapter describes the testing of the data 








transfer application developed, including the test network 
description, the various scenarios that were used, and the 


general results of the testing. 


A. TESTING NETWORK DESCRIPTION 

The testing of the API support application required 
the installation of a basic network that simulates several 
scenarios in which all the application components’ 
operations can be tested. 

1. Practical Considerations and Limitations 

e Home-based wired networking was used for data 

transmission between end users to simulate a small 


network scenario. 





e Both wired and wireless network at the Naval 
Postgraduate School (NPS) were used to simulate the 


Internet network environment. 





e During the test, the IP address of the server was 
assumed to be static. 
e A sufficient number of wired clients and wireless 


enabled devices were used to test the requirements 








of the thesis research. It is not our goal to test 





the volume of client traffic that the application 
can handle. 
e In most of the testing scenarios, the additional 


“delay” during transmission is added to reduce the 





speed of the file transfer and the reconnection 
process. That means the server’s and client’s 


program response was slowed by the use of a “delay” 
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function so that it is easier for the user to 
observe the communication protocol features and 


behavior during the test scenarios. 





e The connectivity failures necessary to test the 
protocol responses were manually caused by either 
unplugging the network connection in the wired 
devices (mainly servers), or by disabling or 
removing the wireless adapters from the wireless 
enabled client devices. 

2. Testing Network 

As Figure 24 shows, for the small network scenario, 

the testing network consists of a server, a client and a 
switch connecting directly for a wired environment. For a 
wireless environment, they are connected via wireless 


adaptors through a router that also connects to the 





Internet. The server in both the wired and wireless setup 


has the static IP address. 


[o] fose505] [25] 
Switch 

































































WirelessRouter 








Figure 24. The home-based networking architecture 
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For the simulated WAN network, the client is 
connecting to the server using wired connection via a 
switch, and wireless connection via a wireless router. As 


shown in Figure 25, the client is connected to the server 





via the NPS network for both wired and wireless WAN 


testing. 







































































Client WirelessRouter 


Figure 25. The NPS-based WAN network setup 


B. TESTING SCENARIOS 


Several tests were developed to emulate the various 





problems that might be encountered while running’ the 





application. These scenarios are used to ensure that the 





goals of the thesis research were fulfilled. The following 


descriptions list all the testing scenarios and associate 





them with a referenc code so that they can be referred 


later in the result description without naming them 








explicitly. Th referenc codes start with a group of 





letters that indicates the general scenario type and ends 








with a counter number. The reference code part that refers 





to the scenario’s type is one of the following: 


e SUIS : Server User Interface Scenario. Situations that 





can happen during the interaction of the server’s user 


with the available user interface. 


e CUIS : Client User Interface Scenario. Situations that 





can happen during the interaction of the client’s user 


with the available user interface. 
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e APIS : API Scenario. Situations that API does during 


the establishment of the new connection for the client 





to the server. 


1. Scenario Reference Code and Scenario’s 
Description 
SUIS-1 The server accepts the connection and waits 


for the request from the client. 








SUIS-2 The server sends the data packets in a TCP 
session. 

SUIS-3 The server sends the video packets in a UDP 
session. 

SUIS-4 The server accepts the new connection and 


disregards the previous connection. 
CUIS-1 Failure in the type of protocol selection 
when it is necessary to select the protocol 


used for transfer. 

















CUIS-2 Starting download in a TCP session. 
CUIS-3 Starting download in a UDP session. 
CUIS-4 Detecting a physical connection lost while 


downloading the packets from the server. 
APIS-1 During the file transfer, the connection is 


lost but is restored again after a short 





period of time. The ConnectionControl object 
performs the task instead of the client. 


CUIS-5 Display confirmation to th user befor 





closing the current session. 
Cc. TESTING RESULTS 
This section explains how the network components 
responded to each of the scenarios and how the user 


interface helped the user to be informed if a file transfer 
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failed during its operation. The reference codes listed in 


Section A are used to refer to each scenario. 


SUIS-1. The server accepts the connection and waits 
for the request from the client. The result was that 


the program informed the user via a message as 





follows: 
New connection is established! 
oK 
Figure 26. The server establishes the connection 


& Server Process 


Server is waiting for a client to establish the connection... 


Server accepted 
hread #1 created! 


Server is waiting for a client to establish the connection... 


& TCP Counter 


Character # 8736 , Ais sent 





Figure 27. The server is ready for the TCP file transfer 


sae) 


& Server Process 


Server is waiting for a client to establish the connection... 


Server accepted 
hread #1 created! 


Server is waiting for a client to establish the connection... 


& UDP Counter =O] x 





Figure 28. The server is ready for the UDP file transfer 





e SUIS-2. A panel displaying the text sent informs the 


user of the progress for a TCP session. 


g& TCP Counter 


Character # 8736 , Ais sent 





Figure 29. The proxy server process for a TCP session 





e SUIS-3. A panel displaying the frame number sent 


informs the user of the progress for a UDP session. 


g& UDP Counter = |B] x| 





Send frame # 19 


Figure 30. The proxy server process for UDP session 


e SUIS-4. This is the result from a lost connection. The 
server accepts the new connection and disregards the 
previous connection. The new thread is created to 


handle the new communication. 
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mo 
& Server Process 













Server is waiting for a client to establish the connection... 





Server accepted 
hread #1 created! 


Server is waiting for a client to establish the connection... 


hread #2 created! 
Removing thread# 1 


hread# 1 removed! 





Server is waiting for a cient to establish the connection... 


Figure 31. The server process after new connection 


e cCUIS-1 The client user needs to select the type of 
protocol to be transferred in order to avoid an error. 


The panel in Figure 32 appears if the user tries to 





connect before selecting the type of protocol. 


Button Error! 


& Please choose one of the options before hitting the connect button 








Figure 32. The response of client side for CUIS-1 





e CUIS-2. A window displays the content that the client 
received during a TCP session (as shown in Figure 18 
in chapter 4 section B.2.a). 

e CUIS-3. A window displays the video content that the 
client received during a UDP session (as shown in 


Figure 19 in chapter 4 section B.2.a). 
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CUIS-4. When connection failure is detected, a GUI is 
displayed to alert the user, and user action is needed 


for the client to begin the reconnection process. The 





following figures show the sequence of panels 


displayed to the users at the client side: 


Socket closed! 


& The connection has lost, error in the underlying protocol 





Figure 33. The information message of the client (1) 


Next Process 


The next job is to reestalish the session 


Figure 34. The information message of the client (2) 





0 


G sBuilder 9 - C:/CHAYUTRA/Thesis/Connections/RCD/RCD/src/rcd/VideoStream. java 





File Edit Search View Project Run Team Wizards Tools Window Help 




















Se r & % | Reba | 
HES-DEBS|\o~° RBS lMfoimewny Ih ww -| Dd -w-%-|M-¢ O16 
ay i bg RCD jpx a | lier ‘onnectionContral | pac! | erver | erverThr X &% VideoStream 
Be iz jp X ® client | %|®4 ConnectionContral| %/® RTPpacket| x/®% si X &% ServerThread % 
RCD jpx s l/s al 
@ <Project Source> 0 CER ee ge es erg issaccas eae TaSeae 
@D rca 33 
& Standard Doclet °4 public VideoStream(String filename) throws Exception{ 
} la 4 36 /finit variables 
i a Convectioncontroljave hd 37 fis = new FileInputStream(filename) ; 
a 38 frame_nb = 0; 
[2 Imports =) 
fl @ VideoStream 40 } #/ end constructor 
oo © VideoStream(String filename) ie , 
© getnexttrame(byte[] frame) a 
fis 43 * Get the next frame 
44 * 
: % trame_nb 45 * @param frame array of byte of the video 
ag * 
49 * Aremirn the next frame as an array nf hwte and the size nf the frame of 
4 > 
|VideoStream java | Insert 6x1 ov CUA Q Y 








Source | Design | Bean | UML | Doc | History 


7 
Got RTP packet with SeqNum # 31 TimeStamp 3100 ms, of type 0 
Got RTP packet with SeqNum # 32 TimeStamp 3200 ms, of type 0 





















Index to read file = 32 
No connection resumed. Still trying to connect to 
No connection resumed. Still trying to connect to 
No connection resumed. Still trying to connect to 
No connection resumed. Still trying to connect to 
No connection resumed. Still trying to comnect to 
No connection resumed. Still trying to connect to 
connection resumed. Still trying to connect to 
connection resumed. Still trying to connect to 




























© D Process finshed 


X Client | % Client] X Client x) Client 





Figure 35. The persistency API’s reconnection process 


e APIS-1 During the file transfer, the connection is 
lost but is restored again after a short period of 
time. The client attempts to reconnect to the server 
by calling the persistency API. The image progress 
panel of the user interface, which displays the image 


or file download progress, stops updating until the 





client reconnects to the server and begins retrieval 
of the rest of the file. Figure 36 shows the attempt 
of the API program to connect to the server as well as 
the paused state of the user interface during 
connection failure. Figures 37 and 38 show the message 
when the connection is resumed, followed by the 
messages showing that the process is continued from 


the point where the connection was lost. 
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Figure 36. 


Figure 37. 


Figure 38. 





& Client 
== Verbose logging started: 9/22/2004 10:29:07 Build type: SHIR} 
UNICODE 2.00.2600.1106 Calling process: CAWINDOWS\Systen = 
32\msiexec.exe === 
MSI (c) (64:F 0): Resetting cached policy values 
MSI (c) (64:F 0): Machine policy value 'Debug'is 0 
MSI (c) (64:F 0): ******* RunEngine: 

weer Product CAWINDOVS\Downloaded InstallatiansiDAE 
MON Tools 3.47idaemon.msi 

ee ACHON: 

wereres(GOmmancline:* 
MSI (c) (64:F 0): Machine policy value 'DisableUserinstalls' is 0 
MSI (c) (64:F 0): SOFTYVARE RESTRICTION POLICY: Verifying pack 
age --> 'C:WVINDOVYS\Downloaded InstallationsiDAEMON Tools 3 
47idaemon.msi' against software restriction policy 
MSI (c) (64:F 0): Note: 1: 2262 2: ODigitalSiqnature 3:-2147287038 


MSI (c) (64:F 0): SOFTWARE RESTRICTION POLICY: CAWINDOVWS 
Downloaded InstallationsiDAEMON Tools 3.47\daemon.msi is no 


The client’s user interface during connection 
failure 


Client Status 


i) Connection resumed!!! 





The message from API showing the status (1) 


Client Status 


& The transmission is continuing from the point it lost! 


The message from API showing the status (2) 
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CUIS-5 There are two panels at the client side running 
at the same time: the client’s control panel (Figure 
16) and the client process panel (Figure 18 for TCP or 
Figure 19 for UDP). Both panels are waiting for the 
action from the user. While the client process is idle 


or still running, if the user wants to quit at any 





time, the application will ask for confirmation before 





leaving the application. The action from pressing the 
“close” button from one of the client’s panels will 


yield the result shown in Figure 39. 


Ask for confirmation 


Do you really want to close? 


[yes || wo 


Figure 39. The final confirmation message 
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VI. CONCLUSION AND FUTURE WORKS 


A. SUMMARY 
The goal of this thesis research was to design an API 
to support persistent session services to various 


applications using TCP or UDP as an underlying protocol, 





and to implement an application that uses and demonstrates 


the operation the persistent session service. Other 





proposed file transfer protocols for service continuity 


were examined to study their characteristics and features 





used to recover from a connection failure. 
The communication program implemented is a client- 
server application that supports multithreading on the 


server side and can dynamically recover from data transfer 





failure due to intermittent physical connection loss. This 
file recovery feature is achieved by designing and 
implementing the API at the client Side. The 


ConnectionControl object, when called by the client 





application, tries repeatedly to connect to the server and 
resume the data transfer session from the point where 
connection failure occurs. 


The application was designed with user interfaces that 





make the dynamic partial file retrieval visible to the user 





in real time. Special user interface panels are created to 





show the file transfer progress and display the data 
received. 

The main scenario tested during the communication 
application testing was when the connection failed during 
the file transfer and the client program successfully 


reconnected when the physical connection was restored. Our 








test also validated the file management and the 
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multithreaded behavior at the server side. Both wired and 





wireless network environments were used in testing at the 


client 





Side. Users at the client side were able to 








visualize the file transfer progress and control the file 





transfer options (request file, stop downloading, or choose 


to continue previous failed file transfers). 


B. FUTURE WORK 














Extending the research scope of this thesis and the 
application developed in support of it, there are issues 
that raise opportunities for further research. They 
include: 

1. Communication Protocol Design 


Based on the APIs developed in this thesis’ for 





specific applications, further research could be focused on 


enhancing the API to have more capability. Some key areas 


towards 


this direction could be: 


Support a fully mobile networking environment. 


Further enhancement in the API can be supported for 





portable devices with respect to data session 





survivability in a wireless environment. The API may 
have more capability but should be small enough to 


be more suitable for mobile device. 


Support for migration of UDP sessions. As discussed 


in Chapter II, migration in TCP has been studied. 





Further research can be done on enhancing the 


service continuity for both kinds of protocol. 


Lower level API. The API may be written using the 





concept developed in this thesis but implemented at 








the lower level of the network stack to achieve 


better performance. 
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2. 
In 
further 


Application Development 








application-level development, the following 
work can be done: 
Extending the persistency API class library. Create 
a class or additional API library for the persistent 





connection protocol that application developers can 





use to develop new applications. This proposed API 
should be able to support generic applications at 
the application layer, CuiGag it supports all 
applications using either TCP or UDP as_ the 
underlying protocol. 

Developing additional applications that use 
persistent data sessions. Examine other types of 
applications where applying the persistent data 


sessions can be useful. 
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APPENDIX A. CLASS SOURCE CODE 























[** 

* Title: API Development for Persistent Data Sessions 
Support 

* Description: Application client 

* Compiler : JBuilder 9 

* Author CPT.Chayutra Pailom THA 

* Date : January 20, 2005 

ne 

import java.io.*; 

import java.net.*; 

import java.awt.*; 

import java.awt.event.*; 

import jJavax.swing.*; 

import javax.swing.Timer; 

[** 


* This is part of the connection process which is connect 
to the server. 

* This client is intended to connect and receive the data 
from the server 

* using two different protocols; TCP and UDP. This class 
is intended to 

* use socket programming for both types of protocols and 
graphic user 
interface on order to interact with the user. 




















* Expected server protocol support: Both TCP and UDP 
applications 





* 


* @author CPT Chayutra Pailom THA 
ag 


public class Client extends JFrame implements Runnable { 


//---- Global variables for TCP or UDP process ----/ 





/** Runnable TCP or UDP object */ 
private Thread TCPThread, UDPThread; 
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pee The physical connection control.process. */ 
private ConnectionControl controlAgent; 


/** Socket for TCP and RTSP request */ 
private Socket socket; 


jee The. burter -for input-stream */ 
private BufferedReader br; 


jer The butter for output stream */ 
private BufferedWriter bw; 


/** The IP address of the server */ 
private String host; 





/** Port to communicate with the server */ 
private int port; 








/** Logic to control the redundant. data manipulation */ 
private boolean knowSize; 





/** Logic for doing TCP or UDP process */ 
private int connectionCase; 


j** The critical variable for reconnect process for 
both TCP and UDP */ 
private int index; 








/** Connection status */ 
private boolean connect; 


| /------------- GUI for TCP -------------- / 


/** JFrame for TCP process */ 
private JFrame k; 


/** Container to be added onto main frame */ 
private Container container; 





/** The status bar showing how far of TCP process */ 
private JProgressBar progressBar; 


/** The area to show the process and the TCP data */ 
public JTextArea textArea, textArea2; 
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/** The button to shutdown the visibility of the GUI */ 

private JButton buttonClose, buttonClose3; 

/** The button to start retriving the data from the 
server */ 

public JButton buttonConnect, buttonData; 

/** The panels for containing small functions of GUI */ 


private 


fe The 
private 


/** The 
private 


fee TNS 
private 


/** The 
pravebe 


private 


fom Tie 
private 


fre THE 
private 





pee THE 
UDP 
private 





oe Nie 
private 





/** The 
Prive LS 





JPanel TCPPanel, buttonPanel, 
textPanel, textPanel2; 


buttonPanel3, 
container for menu commands */ 
JMenuBar menubar; 


container for menu items */ 
JMenu menuCommand; 


function for scrolling the text area */ 
JScrollPane scrollPane, scrollPane2; 











items to be chosen for data manipulation */ 
JMenulItem size, filePersistent,filePersistent2; 





main frame of the UDP process */ 
JFrame f; 








utton to shutdown 
UDP */ 
JButton buttonClose2; 


the visibility of the GUI 





ton to se 
JBut 


tup and start the video process */ 
ton playButton; 











the video process */ 
ton; 


ton to pause 
JButton pauseBut 





























panel for containing the small functions for 
GUI */ 

JPanel mainPanel; 

contained functional video commands */ 
buttonPanel2; 


panel 
JPanel 














label for the video */ 
JLabel iconLabel; 
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pe* The video to be shown *~/ 
private ImageIcon icon; 





Lp See SSeS ea LCE Vari b les. SSS a See Se Sseee ti 


j** Size of the desired data used for progress. bar */ 
private int fileSize; 


/** The timeout constant for socket */ 
private final int SOCKET TIMEOUT = 5000; 


fl SAA ea Rilor Mat Lables eases / 


/** Boolean stand for the state */ 
private boolean ready; 


/** Sequence number of RTSP messages within session */ 
private static int RTSPSeqNb = 0; 


jes Eng OF command: *7 
private final static String CRLF = "\r\n"; 


/** RTP payload type for MJPEG video */ 
p yp 
private static int MJPEG TYPE = 26; 


eo cee ee eae cima Rae Maid ebles SSeS Saar / 


/** UDP packet received from the server */ 
Pp 
private DatagramPacket rcvdp; 





/** socket to be used to send/receive UDP packets */ 
private DatagramSocket RTPsocket; 





/** port where client will receive the RTP packets */ 
private Static int REP RCV PORT-= 9999" 








/** new port where the client will receive the RTP 
packets */ 
private int newRTPPort; 


/** timer used to receive data from the UDP socket */ 
Timer timer; 
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/** buffer used to store data received from server */ 
byte[] buf; 


/, uepee oe e eee eae eee eos aa ae 

// 

ia Constructor: 

// 

[Pers See Sar nA S eee SSoR esas aa a SSS rae Seana 

[** 

% Dera: “COnSsterucior 

* 

* @€param pHost - IP: address of the. server 

* @param no - port number of the server to be 
connected 

RY. 


public Client(String pHost, int no) { 





// Variables initialization 
host = pHost; 

port = no; 

knowSize = false; 
connectionCase = 0; 

connect = false; 








j/** Initialtze the control. ‘process object. 

* must call in order to avoid incomplete physical 
connection */ 

fileControl(this, port, host); 











[ (Vea ee es Cliewe GUlt PEOCess.~S=sss-2e—— i 


// Main frame attributes 

container = getContentPane(); 
container.setLayout (new BorderLayout()); 
this.setTitle ("Client"); 
this.setSize(400, 400); 
this.setLocation(500, 0); 























// buttons,labels and panels 


























buttonClose = new JButton("Close"); 
buttonConnect = new JButton("Connect") ; 
buttonPanel = new JPanel (); 

textPanel = new JPanel (); 
buttonPanel.add(buttonClose) ; 
buttonPanel.add(buttonConnect) ; 
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// menu items for the client commands 





























size = new JMenulItem("Get Size"); 

filePersistent new JMenulItem("Get File TCP 
PERSISTENT") ; 

filePersistent2 new JMenulIltem("Get File UDP 
PERSISTENT"); 








// menu for the items to be added 
menubar = new JMenuBar(); 
menuCommand = new JMenu ("Command"); 
menuCommand.add(size); 
menuCommand.add(filePersistent) ; 
menuCommand.add(filePersistent2) ; 
menubar.add(menuCommand) ; 
this.setJMenuBar (menubar) ; 
































// Initialize handlers 
ButtonHandler buttonHandler = new ButtonHandler(); 
MenuHandler menuHandler = new MenuHandler (); 








// action listeners for buttons 
buttonClose.addActionListener (buttonHandler) ; 
buttonConnect.addActionListener (buttonHandler) ; 

















// action listeners for menu commands 
size.addActionListener (menuHandler) ; 
filePersistent.addActionListener (menuHandler) ; 
filePersistent2.addActionListener (menuHandler) ; 

















// text components 

textArea = new JTextArea(); 
textArea.setLineWrap (true); 
textArea.setEditable(false); 

scrollPane = new JScrollPane(textArea) ;; 
































// border layout placements 
textPanel.setLayout (new BorderLayout ()); 
textPanel.add(scrollPane, "Center"); 
container.add(textPanel, "Center"); 
container.add(buttonPanel, "South"); 























setVisible(true); // set the visibility of the main 
GUI 





textArea.append("Client is ready\n"); 
LtextArea.append("Please choose one of the commands 
at the command bar\n"); 
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// frame for TCP GUI 
k = new JFrame("Client TCP Process"); 





// add frame window attribute 
k.addWindowListener (new WindowAdapter() { 
public void windowClosing(WindowEvent e) { 
System.exit(0); 








} 
}); 


// TCP process frame attributes 
k.setTitle ("Client"); 
k.setSize(400, 400); 
k.setLocation(0, 0); 





// buttons and panels 
TCPPanel = new JPanel (); 

















buttonPanel3 = new JPanel (); 
textPanel2 = new JPanel (); 

buttonData = new JButton("Get Data"); 
buttonClose3 = new JButton ("Close") ; 





// action listeners for buttons 
buttonClose3.addActionListener (buttonHandler) ; 
buttonData.addActionListener (buttonHandler); 




















// text components 

textArea2 = new JTextArea(); 
textArea2.setLineWrap (true) ; 
textArea2.setEditable (false) ; 

scrollPane2 = new JScrollPane(textArea2) ; 
progressBar = new JProgressBar(); 



































// Add buttons into button panel 
buttonPanel3.setLayout (new GridLayout(l, 0)); 
buttonPanel3.add(buttonData) ; 
buttonPanel3.add(buttonClose3) ; 



































// border layout placements 
textPanel2.setLayout (new BorderLayout()); 
textPanel2.add(scrollPane2, "Center"); 
textPanel2.add(progressBar, "South"); 
TCPPanel.setLayout (null); 
TCPPanel.add(textPanel2, "Center"); 
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TCPPanel.add(bu 





// panel 


textPanel2.setBo 
tonPanel3.setBounds 





but 


attr 





ibutes 


unds (0 








tonPanel3, 


y 0, 
(0, 


310, 


"South"); 


380, 315) 


380, 


// Add TCP main panel into JFrame 
k.getContentPane().add(TCPPanel, 
BorderLayout.CENTER) ; 


// frame for UDP GUI 


f 


// add frame window at 


new JFrame ("Client 





UDP GUI Process 


ttribute 


. 
, 


50); 


t UDP Process"); 


f.addWindowListener (new WindowAdapter () 
public void windowClosing(WindowEvent e) { 








System.exit(0); 


} 
}); 


// buttons and panel 





playBut 
pauseButt 
buttonClo 
mainPanel 
buttonPan 




















// Add bu 
buttonPan 
buttonPan 
buttonPan 
buttonPan 























ton = new JButt 


on 
se2 


el2 


tton 
el2. 





el2. 
el2. 
el2. 


initial 


ization 








new JBu 
new JB 


u 











s into bu 
setLayout 
add (playB 





add (pauseBu 





u 














ton("Play"); 

ton ("Pause") ; 
tton("Close VDO"); 
new JPanel (); 
new JPanel (); 


ton panel 
(new GridLayout (1, 
Eon); 
tton) ; 


add (buttonClose2); 


// Add action listener for each button 
playButton.addActionListener (new 
// create object play 


playButt 





pauseBut 





tonListener()); 
pauseButton.addActionListener (new 
ttonListener());// creat 


{ 


O)); 








te object teardown 





buttonClose2.addActionListener (buttonHandler) ; 


// Image display label 
iconLabel = new JLabel 
iconLabel.setiIcon (null 

















(); 
); 
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// frame layout 
mainPanel.setLayout (null); 
mainPanel.add(iconLabel) ; 
mainPanel.add(buttonPanel2) ; 








// Set boundary 
iconLabel.setBounds(0, 0, 380, 315); 
buttonPanel2.setBounds (0, 310, 380, 50); 





// Add main panel into JFrame 
f.getContentPane().add(mainPanel, 
BorderLayout.CENTER) ; 
f.setSize(new Dimension(390, 400)); 





// init timer for video 

timer = new Timer(20, new timerListener()); // 
create object timer 
timer.setInitialDelay (0); 
timer.setCoalesce (true) ; 











//allocate enough memory for the buffer used to 
receive data from the server 
buf = new byte[15000]; 





} // end constructor 


* Runs a thread, it has to be run as a thread in order 
to achieve the GUI. 

* There are two types of the protocols; TCP and UDP, 
depending on the 

* connectionCase. When a physical lost occurs, in 
order to achieve 

* the persistent data sessions, the client will ask 

the server to send 

data again by using the previous parameters. It 

seems to be non-persistent 

* due to the new establishment of the connection but 

the idea of persistent 

connection will be used instead. 
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public vole Hunt): 4 
if (connectionCase == 1) 
TCPStart (); 
else 
UDPStart (); 
} // end run() 
/** 
* Method to close all socket variables 


ay 


public void close() { 





try { 


if (br '!= null) f 
br.close(); 
} // end if 


if (bw != null) { 
bw.close(); 
Loh “ames i 





if (socket != null) f 
socket.close(); 
ib £/f vend) Ft 


} catch (java.io.IOException io) { 


JOptionPane.showMessageDialog(this, "Input / 
Output error occured, you should restart", 
"Socket closed error", 

JOptionPane. INFORMATION MESSAGE) ; 





} // end try - catch 


} // end close() 


[** 
* Method to open all socket variables 
* 


* @return boolean true if the connection can be 
established otherwise false 
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ay 


public boolean open() { 
try { 


System.out.printlin("Trying to connect to the 
server...."); 
/** use for both TCP request and RTSP request 
(for later UDP) 

* automatically connect to the host(server) */ 
socket = new Socket (host, port); // ==> 
System.out.println("After create socket, 

connection ==> " + socket.isConnected()); 
connect = true; 




















// initialize buffer for both input and output 
streams, use socket for initialization 

br = new BufferedReader (new 

InputStreamReader (socket.getInputStream())); 

bw = new BufferedWriter (new 

OutputStreamWriter (socket.getOutputStream())); 























} catch (UnknownHostException uhe) { 


JOptionPane.showMessageDialog(this, "Unknown 
server, check the address"); 
return false; 


} catch (IOException ioe) { 


JOptionPane.showMessageDialog(this, "Cannot 
connect to the server, server may be down or 
cable unplugged.", "Socket Error!", 
JOptionPane. INFORMATION MESSAGE) ; 








return false; 
} // end try - catch 
return true? // ‘Lf success 
} // end open() 


[** 
* Method to send the message to the server 
* 


* @param message - the string request 
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ay 


public void send(String message) { 


try { 





// write the message to the server using buffer 
writer 

bw.write (message) ; 

bw.newLine () ; 

bw. flush (); 





} catch (SocketException se) { 





// true if the socket successfully connected to 
the server 
if (socket.isConnected()) { 
JOptionPane.showMessageDialog(this, "The 
connection still established!"); 
} else { 
JOptionPane.showMessageDialog(this, "Other 
problems!"); 
} // end if - else 





} catch (Exception e) { 


JOptionPane.showMessageDialog(this, 
"Tn send, Check if connected to server", 
"Sending Error!", JOptionPane.ERROR_ MESSAGE) ; 





close(); 
} // end try - catch 


} // end send() 


[** 


* Method to send the request to the server 
* 








* @param request type - the UDP request 
mn 
public void send RTSP request (String request_type) { 


try { 





// write the message to the server using buffer 
writer 
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bwowtlve(request type +" Cseq:. ” 4+ RISPSeqnb-+ 
CRLF) ; 
bw. flush (); 


} catch (Exception ex) { 

System.out.println("in send Exception caught: " 
+ ex); 
System.exit (0); 





} // end try - catch 
} // end send _RTSP_ request () 
[** 


* Method to set the parameters after getting new 
connection 





@param socket - the TCP or RTSP communication socket 
@param br - buffer for input stream 
@param bw - buffer for output stream 


+ + + * 


/ 


public void setParameters (Socket socket, BufferedReader 
br, BufferedWriter bw) { 





this.socket = socket; 
this.br = br; 
this.bw = bw; 





} // end setParameters 


[** 
* Method to retrieve the variable host 
* 


* @return host - the IP address of the host 
ag 
public String getHost() { 








return host; 
} // end getHost() 


[** 
*. Method to retrieve the: constant: RTP: RCV PORT 

* 

* @€return RIP RCV PORT = the RIP destination port 
ar 
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public Int. getUDPPert(): 4 
return. (RIP RCV. PORT); 


} // end getUDPPort () 





[** 
* Method to get the random RTP port 
* 
* @return - random RTP port number 
ay 


public int randomRTPPort() { 

return ((int) (Math.random() * 10000)); 
} // end randomRTPPort () 
/** 


* Method to set the random RTP port 
* 





* @param newPort new RTP port numner 
ak 
public void setRandomRTPPort (int newPort) { 


newRTPPort = newPort; 





} // end setRandomRTPPort () 








[** 
* Method to get the random RTP port 
* 
* @param RTPsocket - new RTP socket 
4y 


public void setRTPSocket (DatagramSocket RTPsocket) 





this.RTPsocket = RTPsocket; 
System.out.printin("New RTP socket set!"); 





} // end setRTPSocket () 
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+ 


Connect to the server either TCP or UDP 
This client will not be terminated unless 
the appropriate button will be pressed. 

















Five steps to communicate with the client are 

tep 1 - Set up a client socket to send request 
o the server 
tep 2 - Set up the control agent 
tep 3 - Open appropriate streams for desired 
ata exchange 
tep 4 - Communicate with the server via streams 
tep 5 - Close the opened socketconnection 


+ + + + FF OF 

















NANDNNGN 


ai 


[** 
* Persistent TCP connection 
* 
‘“ 
private void TCPStart() { 





// variable initialization 


index = 0; 

String text = ""; 

boolean done = false; 

if ((knowSize == false) && (connect == false)) { 
open(); // open the port for the TCP 


connection 
textArea.append("Connected\n") ; 





// get the size of the data in order to 
manipulate the progress bar 























fileSize = findSize(); 
} of 7 -end- Lt 
while (!done) { 
System.out.println("In while loop"); 
String £éxtout =."/géet "+ andéx; 
System.out.println("Command --> " + 
textOut) ; 


System.out.println("Request to server 
sent!"); 
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send(textOut); // send the request to the 


server 
int spaceCounter = 0; 
char[] testChar = new char[4]; 


// receive the content of the file until EOF 


while (!socket.isClosed()) f 
try { 
try { 


socket.setSoTimeout (SOCKET TIMEOUT 
if ff set timeout. for the. TCP 
socket 





} catch (SocketException se) { 


JOptionPane.showMessageDialog(this, 
"The connection has lost, error 
in the underlying protocol", 
"Timeout!", 

JOptionPane.ERROR MESSAGE) ; 





JOptionPane.showMessageDialog(this, 
"The next job is to reestalish 
the session", "Next Process", 
JOptionPane. INFORMATION MESSAGE) ; 





close()<¢ /f €1lose all sockets 
before doing reconnection 


// Lt the connection: is. lost by 
timeout, it will reconnect 
automatically 








controlAgent.reconnectProcess ("TCP") ; 
} // end try - catch 


text = br.readLine(); // read the 

incoming response from the server 

System.out.println("Received ==> " 4 
text + " , index = " + index); 
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// very important for retrieving the 
rest of the data 
controlAgent.setIndex (index) ; 





VE) CLEXP equals tonorecase(!'))r a 


System.out.println("spaceCounter = 
"+ spaceCounter) ; 
spaceCountertt; 








if (spaceCounter == 3) { 


textArea2.append("\n") ; 
spaceCounter = 0; 


by Vf end at 
} elsef 


textArea2.append (text); 
spaceCounter = 0; 


} // end if - else 





if (text != null) { 


index++; // increment the 
counter 
progressBar.setValue (index); // 
set the progress bar 


// End of file 
if ((index) == fileSize) f 





textArea2.append("\n") ; 





JOptionPane.showMessageDialog 
(this, "End of File!"); 


done = true; // set the logic 
to exit the outer loop 
break; // exit the inner loop 





} ff vend at 


} // end if 
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} catch (NoRouteToHostException nrth) { 


JOptionPane.showMessageDialog(this, 
"The route to host!"); 
JOptionPane.showMessageDialog(this, 
"The next job is to reestalish 
the session"); 
} catch (ConnectException ce) { 




















JOptionPane.showMessageDialog (this, 
"The connection was refused 
remotely"); 

JOptionPane.showMessageDialog(this, 
"The next job is to reestalish 
the session"); 

} catch (SocketException se) { 





System.out.printlin("The error is 








===> " + se.getMessage()); 
close(); // close the socket and I/O 
streams to quit inner loop 





JOptionPane.showMessageDialog(this, 
"The connection has lost, error 
in the underlying protocol", 
"Socket closed!", 
JOptionPane.ERROR MESSAGE) ; 

JOptionPane.showMessageDialog (this, 
"The next job is to reestalish 
the session", "Next Process", 
JOptionPane. INFORMATION MESSAGE) ; 











[** 

After the physical connection is 

lost, 

* the client socket will be closed 
and the agent 

* is trying to establish the new 
commnication 


* <p> 

Five steps to communicate with 

the client are 

> Step 1 - Close the opened 
socket 
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tep 2 - Call agent to do the 
econnect process 

tep 3 - Do the iteration until 
he connection is resumed 

tep 4 - Continue communicate 
ith the server via streams 

tep 5 - Get the rest of the 
ata until the end of the file 














+ 
Ans NAHNKN 





ae 


// type of protocol should be passed 
controlAgent.reconnectProcess ("TCP") ; 








} catch (IOException io) { 
} // end try - catch 
} // end inner while 
} // end outer while 
textArea.append("\n"); 
textArea.append (String.valueOf (socket.isClosed() ) 
ee ee ee ee ere "End of 


Pale) 2 


} // end TCPStart () 





[** 
* Persistent UDP connection 
ay 
private void UDPStart() { 
System.out.println("Random port = " + 
randomRTPPort()); 
BEY 
if ((knowSize == false) && (connect == 
false)) { 
open (); 
textArea.append("Connected\n") ; 
fileSize = findSize(); 
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b ff end 2 


[** 


construct a new DatagramSocket to 
receive RTP packets 


* from the Server; on port. ‘REP RCV PORT: */ 
RTPsocket = new 
DatagramSocket (RTP_RCV_ PORT); 


} catch 





sys 





JOp 





(SocketException se) { 


timer.stop(); 


tem.out.println("Socket exception: " + 
se); 
tionPane.showMessageDialog(this, "The 


connection has lost, error in the 
underlying protocol"); 


} // end try - catch 


ready = 


setupUDPSession(); 











// add text onto the GUI panel 














the 


textArea.append("\n"); 
textArea.append("Now waiting for the action from 


user...\n"); 


} // end UDPStart () 








[** 
* UDP session initialization 
foi 
private boolean setupUDPSession() { 


//init RTSP sequence number 


RTSPSeqNb 


= ute 


/** Send SETUP message to the server to start the 





video then wait for listener for the next 
action */ 
send("/Setup " + RTSPSeqNb + " " + RTP RCV_PORT) ; 


return true; 


} // end set 





tupUDPSession () 
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+ + + + F F OF 


ey 


Method to control the physical connection 


@param client - the string request 
@param port - port for TCP connection 
@param host - IP address of the server 











private void fileControl(Client client, int port, 
String host) { 





controlAgent = new ConnectionControl (client, 
port, host); 


b f/f end: fi beCont rol) 


[** 

* Method to find the size of the file 

* 

* @return size the size of the file in bytes 
aw 


private int findSize() { 
int size = 0; 
try { 
open (); 


String text = new String(""); 

send("/size"); 

textArea.append("Now getting the file size from 
the server..."); 

text = br.readLine(); 

textArea.append(" ---> " + text + " bytes\n"); 




















if (knowSize == false) { 


size = Integer.parselInt (text); 
knowSize = true; 


bb Gy -end: at 
progressBar.setMaximum(size - 3); 
} catch (NumberFormatException ex) { 


System.out.println(ex.getMessage()); 
} catch (IOException ioex) { 
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System.out.println(ioex.getMessage()); 
} catch (NullPointerException npe) { 
System.out.println(npe.getMessage()); 

















} 


return size; 
} // end findSize() 


[** 
* Method to parse the request from the server 
aed 


public void parse server response() { 








try { 





System.out.println("in parse server response(), 


waiting for response..."); 








textArea.append("\nin parse server response(), 





waiting for response..."); 
//parse request line and extract the 
request type: 
String requestLine = br.readLine(); 


System.out.printlin("RTSP Client - Received from 


Server:"); 
System.out.println("Received --> " + 
requestLine) ; 














textArea.append("\nReceived --> " + requestLine) ; 


if (requestLine.equalsIgnoreCase("EOF")) { 


JOptionPane.showMessageDialog(this, "End of the 


video"); 
ready = false; 


int reply = JOptionPane.showConfirmDialog(null, 
"Would like to see again?" , "Ask for your 
permission", JOptionPane.YES NO OPTION) ; 


if (reply == JOptionPane.YES OPTION) 





JOptionPane.showMessageDialog(this, "Please 
press Play button to sees it again"); 
else { 
JOptionPane.showMessageDialog(this, "Return 
to main menu"); 
f.setVisible (false); 
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b ff end At =—“elee 4 
} catch (Exception ex) { 


System.out.println("Exception caught: " + ex); 
System.exit (0); 





} // end try - catch 


} // end parse RTSP_ request () 


[** 
* Main method to start the client 
* 





* @param arg argument list 
eg 


public static void main(String arg[]) { 





Client client; 





if (arg.length != 2) { 

System.out.println("Usage: java Client 
<hostname> <portnumber>") ; 
System.exit( -1); 








} 


client = new Client(arg[0], 
Integer.parselInt(arg[1])); 





// exits when the window is closed 
client.addWindowListener (new WindowAdapter() { 
public void windowClosing(WindowEvent e) { 








System.exit( -1); 


} 
\e 


} // end main () 
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private class MenuHandler implements ActionListener { 





public void actionPerformed(ActionEvent e) { 


if (e.getSource().equals(size)) { 
open (); 
fileSize = findSize(); 


} else if 
(e.getSource().equals(filePersistent)) { 


connectionCase = 1; 





textArea.append("\nTCP connection 

selected!\n"); 

LtextArea.append(Please press connect button 
to receive: the data... \n")\¢ 











} else if 
(e.getSource().equals(filePersistent2)) { 


// do UDP 
connectionCase = 2; 
UDPThread = new Thread(Client.this); 





textArea.append("\nUDP connection 

selected!\n"); 

textArea.append("Please press connect 
buttom to receive the data. ....\n")> 











} // end if - else if 
} // end actionPerform() 


} // end class MenuHandler 
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private class ButtonHandler extends 
ActionListener f 


JFrame implements 


public void actionPerformed(ActionEvent e) { 


if (e.getSource().equals(buttonClose)) { 


System.exit(0); 


} else if (e.getSource().equals (buttonClose2) ) { 


RTSPSeqNbt++; 


//Send CLOSE message to 


the server 


send RTSP request (“CLOSE”); 


button pressed! \n"); 








timer.stop(); 
f.setVisible(false); // 





textArea.append("\nClient Process Close 


disable the 


visibility of the GUI 


jJelse if (e.getSource().equals (buttonConnect) ) { 


textArea.append("\nButto 
pressed!\n"); 





if (connectionCase == 0) 


JOptionPane.showMessag 


n Connect 


{ 


eDialog(this, 


"Please choose one of the options 
before hitting the connect button", 


"Button Error!", 





JOptionPane.BRROR_ MESSAGE) ; 


} else if (connectionCas 





k.setVisible (true); 
findSize(); 


} else { 
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e== 1) { 


// Set the JFrame 
visible 


f.setVisible(true); // Set the JFrame 
visible 
findSize(); 


UDPThread.start();// start the UDP 
persistent process 


} // end if - else 


} else if (e.getSource().equals (buttonClose3) ) { 





textArea.append("\nTCP Close button 
pressed! \n"); 
TCPThread.suspend(); 


int reply = 
JOptionPane.showConfirmDialog(this, "Do 
you really want to close?", "Ask for 
confirmation", 
JOptionPane.YES NO OPTION); 


if. (reply == JOptionPane.YES OPTION) 4 


TCPThread.stop(); 

textArea2.setText(""); 

k.setVisible(false); // disable the 
visibility of the GUI 





} else { 
TCPThread. resume () ; 
} 
} else if (e.getSource().equals(buttonData)) { 


textArea.append("\nNow receiving the data 
from: the server ....\n"); 


TCPThread = new Thread(Client.this); 
TCPThread.start();// start the TCP 
persistent process 


} // end if - else if 


} // end actionPerform() 
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} // end class ButtonHandler 





private class playButtonListener implements 
ActionListener {f 


public void actionPerformed(ActionEvent e) { 


System.out.printin("Play Button pressed !"); 
textArea.append("\n"); 
textArea.append("Play Button pressed !"); 
textArea.append("\n") ; 























if (ready == false) { 
ready = setupUDPSession(); 
eff end: Af 


//increase RTSP sequence number 
RTSPSeqNb++; 


//Send PLAY message to the server 

send RISE request ("PLAY") 3 

textArea.append("Now receiving the video from 
the server...\n"); 


//state = PLAYING; 
System.out.println("New RTSP state:PLAYING") ; 





//start the timer 
timer.start(); 





} // end actionPerformed () 


} // end inner class playButtonListener 


class pauseButtonListener implements ActionListener { 





public void actionPerformed(ActionEvent e) { 
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System.out.println("Pause Button pressed !"); 


textArea.append("\n"); 
textArea.append("Pause Button pressed !"); 


textArea.append("\n") ; 




















//increase RTSP sequence number 
RTSPSeqNb++; 


//Send TEARDOWN message to the server 

send RISP request (“PAUSE® )y 

textArea.append("The video will be paused and 
walt for the action cs.\n"); 


//stop the timer 
timer.stop(); 





} // end actionPerformed () 


} // end inner class tearButtonListener 


class timerListener extends JFrame implements 
ActionListener {f 


public void actionPerformed(ActionEvent ev) { 





//Construct a DatagramPacket to receive data 


from the UDP socket 
revdp = new DatagramPacket (buf, buf.length); 





try { 


// Set TimeOut value of the socket. 
RTPsocket.setSoTimeout (SOCKET TIMEOUT) ; 


//receive the DP from the socket: 
RTPsocket. receive (rcvdp) ; 


//create an RTPpacket object from the DP 
RTPpacket rtp packet = new 
RTPpacket (rcvdp.getData(), 
revdp.getLength()); 
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} ca 


al 


//print important header fields of the RTP 
packet received: 

System.out.println("Got RTP packet with 
SeqNum # " + 
PEP. packet. geLsequencenumber (). a” 
TimeStamp " + rtp packet.gettimestamp () 
+ "ms, of type " + 
rtp_packet.getpayloadtype()); 











index = rtp _packet.getsequencenumber (); 
controlAgent.setIndex(index); // set the 
reference of the video 








//get the payload bitstream from the 
RTPpacket object 

int payload length = 

rtp _packet.getpayload_ length (); 

byte[] payload = new byte[payload_length]; 





rtp _packet.getpayload (payload) ; 


//get an Image object from the payload 
bitstream 
Toolkit toolkit = 
Toolkit.getDefaultToolkit(); 
Image image = toolkit.createImage (payload, 
QO, payload_ length) ; 





//display the image as an ImageIcon object 
icon = new ImagelIcon (image) ; 
iconLabel.setIcon (icon) ; 

















tch (InterruptedIOException iioe) { 
(ready == true ) { 
System.out.println("In timer 
InterruptIOException caught: " + 
jioe.getMessage()); 
System.out.println("Seq num = " + index); 
timer.stop(); 
System.out.println(timer.isRunning()); 

















close(); // close the socket and I/O 
streams to quit inner loop 








JOptionPane.showMessageDialog(this, "The 
connection has lost, error in the 
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underlying protocol”,. “socket: closed", 
JOptionPane.BRROR_ MESSAGE) ; 


JOptionPane.showMessageDialog(this, "The 














next job is to reestalish the session", 
"Next Process", 
JOptionPane. INFORMATION MESSAGE) ; 





After the physical connection is lost, 


* the client socket will be closed and the 


agent 


* is trying to establish the new 


commnication 


<p> 

Five steps to 
client are 

tep 1 - Clo 
tep 2 - Cal 


tep 3 - Do 


tep 4 - Con 


+ 
Ny NQ NK NN 





tep 5 - Get 


onnection is resumed 


communicate with the 


se the opened socket 
1 agent to do the 





econnect process 


the iteration until the 








tinue communicate with the 


erver via streams 


the rest of the data 


until the end of the file 


my 


// type of protoc 


ol should be passed on 








controlAgent.reco 


} 


nnectProcess ("UDP"); 














} catch (IOException ioe) { 
System.out.printin(" in timer IOException 
caught: " + ioe.getMessage()); 
} catch (Exception e) { 
System.out.printin(" in timer Exception 
caught: " 4 .getMessage()); 





} // end try - catch 


} // end actionPerformed ( 


) 


} // end inner class timerListener 


t Lh @ndi ass (OLient 
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[** 


* 





Title: API Development for Persistent Data Sessions 
Support 



































* Description: Persistency API class 

* Compiler : JBuilder 9 

* Author CPT.Chayutra Pailom THA 

* Date : January 20, 2005 

we 

import java.io.*; 

import java.net.*; 

import java.awt.*; 

import java.util.*; 

import jJava.awt.event.*; 

import javax.swing.*; 

[** 

* This is the critical part of the project. This class is 
intended to be an API 

* to reconnect and send a request instead of the real 
client. It will be activated 

* after the physical connection is lost and it will try to 
detect and reestablish 

* the new connection between the client and the server. 
Finally if the connection 

* is resumed, it will return the parameters and the rest 
of the process back to 

* the real client. This class is intended to be a 
universal function for the 

* reconnection. The type of protocol,'TCP' or 'UDP', is 
required to be passed 

* through this function inorder to do the different job 
for sending the request. 
Expected method: reconnectProcess() - it will do the 
iteration forever unless 

* the physical connection is resumed 

* 

* @author CPT Chayutra Pailom THA 

*/ 


public class ConnectionControl { 
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/** The client 


object of the project */ 
private Client ; 


client; 











fy CT 


/** Socket for TCP and RTSP request */ 
private Socket socket; 


/** Port to communicate with the server */ 
private int port; 








/** The IP address of the server */ 
private String host; 


fre The butter for input stream: */ 
private BufferedReader br; 


w 


j** The buffer for output stream */ 
private BufferedWriter bw; 








w 





/** The reference of the file for TCP and UDP before the 
lost connection */ 
private int index; 











/** Logic to control the iteration */ 
private boolean done; 








/** socket to be used to send and receive UDP packets */ 
private static DatagramSocket RTPsocket; 




















If Pee eS SS ee eee SS 
es 

// Constructor: 

Af 

TO ana a en alc a on laren ml a a al i ee a eae len el a 
[** 

* Default constructor 

* 

* @param client - client object 

* @param port - port number for TCP, RTSP communication 
* @param host - IP address of the server 

ard 
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public ConnectionControl(Client client, int port, String 








host) f 
this.client = client; 
this.port = port; 
this.host = host; 











initialization(); 





} // end constructor 


[** 
* Method to initialize the important parameters 
AY. 


public void initialization() { 











index = 0; //very important to retrieve the content of 


the file 
done = false; // variable for the iteration for doing 


the new connection 





) (fend indtial izeation } 





[** 
* Method to reconnect the communication between the 
client and the server 
* 
* @param type - type of protocol to be passed on this 
fuction 
* 


public void reconnectProcess (String type) { 











System.out.println("Trying to establish the 
connection..."); 
System.out.println("Index to read file = " + index); 











client.buttonData.setText ("Pause") ; 


[** 
* Reconnect to the server either TCP or UDP 


* This object is trying to help the client to detect 
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* the physical connection. If the connection is 
resumed 

it will send the request either TCP or RTSP for the 

client and then return the value to the client. The 
client 

* will continue its job until the end of the file. 




















Five steps to reconnect the communication with the 
server are 


* Step 1 - Trying to establish the connection via 
the socket 
x Step 2 - If it is resumed, open appropriate 








streams for desired data exchange. If it is not, 
loop forever 

Step 3 - Communicate with the server via streams 
by asking and sending the new request to the server 
using 'index' as an offset of the retrieved file. 























x Step 4 - Set the parameters back to the client 
(socket, br bw) 
* Step 5 - Return the process back to the client 














(or.readLine() ) 
aed 


while (!done) { 
try. 4 


/** create new socket, automatically connected if 
the physical 

* connection resumed 

ae A 

socket = new Socket (host, port); 

JOptionPane.showMessageDialog(client, 
"Connection resumed!!!", "Client Status", 
JOptionPane. INFORMATION MESSAGE) ; 








// if success, it will print. If not it will go 
to the exception 
System.out.println("After create socket, 
connection ==> " + socket.isConnected()); 
open (); 








// set 


client 


the new parameters for the client 
.setParameters (socket, br, bw); 





ct ct 


if (type.equalsIgnoreCase("TCP")) { 
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System.out.println("Type = " + type); 
sendTCPRequest () ; 


} else { 


try { 





System.out.println("Type = " + type); 
sendUDPRequest () ; 


} catch (Exception e) {} 
} // end if - else 
done = true; // set the exit of the loop 


} catch (UnknownHostException uhe) { 





JOptionPane.showMessageDialog(client, "Unknown 
server, check the address"); 
} catch (IOException ioe) { 


System.out.println("No connection resumed. Still 
trying to connect to the server..... Mie 
BEY of 





Thread.sleep (200); 
} catch (Exception e) {} 
} f/ end try = catch 
} //end while 


} // end reconnectProcess() 





[** 
* Method to set the reference of the file 
* 
* @param index - the offset the fil 
xf 


public void setIndex(int index) { 











this.index = index; 


} // end setIndex () 





* Method to open all socket variables 





private void open() { 
try { 


br = new BufferedReader (new 
InputStreamReader (socket.getInputStream())); 
bw = new BufferedWriter (new 
OutputStreamWriter (socket.getOutputStream())); 

















} catch (UnknownHostException uhe) { 





JOptionPane.showMessageDialog(client, "Unknown 
server, check the address"); 


} catch (IOException ioe) { 


JOptionPane.showMessageDialog(client, "Cannot connect 
to the server, server may be down"); 





} // end try - catch 


} // end open() 





[** 
* Method to send TCP request to the server instead of 
the client 
a 
private void sendTCPRequest() { 
String textOut = "/get ™ + index; 





System.out.println("Command --> " + textOut); 

JOptionPane.showMessageDialog(client, "The transmission 
is continuing from the point it lost!", "Client 
Status", JOptionPane. INFORMATION MESSAGE) ; 











client.buttonData.setText ("Get Data"); 
client.send(textOut) ; 














} // end sendUDPRequest () 


[** 
* Method to send UDP request to the server instead of 
the client 
* 
* @throws Exception 
*/. 


private void sendUDPRequest() throws Exception { 





JOptionPane.showMessageDialog(client, "The video is 
continuing from the point it lost!", "Client Status", 
JOptionPane. INFORMATION MESSAGE) ; 











int newRTPPort = client.randomRTPPort(); 
System.out.println("New port = " + newRTPPort); 


/** construct a new DatagramSocket to receive RTP 
packets from the server, on port RIP. RCV-PORT. */ 
RTPsocket = new DatagramSocket (newRTPPort) ; 











client.setRTPSocket (RTPsocket) ; 
client.setRandomRTPPort (newRTPPort); 




















// send the requests to get the video 
client.send("/Setup “ + index + " " + newRTPPort); 
client.send RTSP request ("PLAY") ; 














client.textArea.append("\nSetup and Play requests 
senti\n") +; 


client.timer.start(); // continue the timer after 
sending the new request 








client.parse server response (); 


} // end sendRequest () 








} // end class ConnectionControl 


[** 

* Title: API Development for Persistent Data Sessions 
Support 

Description: RTP packets for video file transfer 

Compiler : JBuilder 9 

Author CPT.Chayutra Pailom THA 

Date : January 20, 2005 








+ + ee 


y 


public class RTPpacket{ 


/** size of the RTP header: */ 
static int HEADER SIZE = S12 





/** Version fields the RTP header */ 
public int Version; 


/** Padding field */ 
public int Padding; 


/e* Bebension tield */ 
public int Extension; 





/** Contributing source */ 
public int CC; 


jor Mar ker: £1 eg. 7 
public int Marker; 


je* Payload of “Lhe RIP {packet */ 
public int PayloadType; 








/** Sequence number of the RTP packet */ 
public int SequenceNumber; 





amp */ 
TimeStamp; 


/** Timest 
public int 





(T CT 


/** Synchronization source */ 
public int Ssrc; 





/** Bitstream of the RTP header */ 
public byte[] header; 


/** Size of the RTP payload */ 


public int 


payload size; 


/** Bitstream of the RTP payload */ 
public byte[] payload; 


* Set an 
bitstre 


@param 
@param 
@param 
@param 
@param 


/ 


+ + + + F FF OF 


RTPpacket object from header fields and payload 


am 


PType the type of the payload 
Framenb the sequence number 

Time time stamp 

data the array of byte of the data 
deve length the Length. of che:.data 























public RTPpacket (int PType, int Framenb, int Time, 
data, int data_length) { 


// Fill 


Version = 


Padding 
Extensio 


// Fill 


by default header fields: 


2; 
= 0; 


n O; 


changing header fields: 
Number = Framenb; 





Sequenc 


TimeStamp = Time; 


PayloadT 


ype = PType; 


// Build the header bistream: 


header = 


// RTP h 
header [0 
header [0 


new byte[HEADER SIZE]; 


eader 
] = (byte) (header[0] | Version << 7); 
] = (byte) (header[0] | Padding << 5); 
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byte[] 





header[0] = (byte) (header[0] | Extension << 4); 
header[0] = (byte) (header[0] | CC << 3); 
header[1] = (byte) (header[1] | Marker << 7); 
header[1] = (byte) (header[1] | PayloadType << 6); 








// Sequence number 
header[2] = (byte) (SequenceNumber >> 8); 
header[3] = (byte) (SequenceNumber & OXFF); 











// Timestamp , all 32 bits 




















header [4] (byte) (TimeStamp >> 24); 
header[5] = (byte) (TimeStamp >> 16); 
header[6] = (byte) (TimeStamp >> 8); 
header[7] = (byte) (TimeStamp & OxXFF); 
// Synchronization source, all 32 bits 
header[8] = (byte) (Ssrce >> 24); 
header[9] = (byte) (Ssrc >> 16); 
header[10] = (byte) (Ssrce >> 8); 
header[11] = (byte) (Ssrce & OXFF); 

// Fill the payload bitstream: 








payload_size = data_length; 
payload = new byte[data_length]; 





// Fill payload array of byte from data (given in 
parameter of the constructor) 
payload = data; 


} f/ -end constructor 
[** 


* Set an RTPpacket object from the packet bistream 


* 





* @param packet the header of the bitstream 

* @param packet size the total packet size 

mi 
public RTPpacket (byte[] packet, int packet size) { 











// Fill default fields: 


Version = 2; 
Padding = 0; 
Extension = 0; 
CC = 0; 


Marker = 0; 


Ssrce = 0; 


// Check if total packet size is lower than the header 
size 
if (packet size >= HEADER SIZE) { 











// Get the header bitsream: 

header = new byte[HEADER SIZE]; 

for (int i = 0; i < HEADER SIZE; i++) 
header[i] = packet[i]; 











// Get the payload bitstream: 
payload _ size = packet size - HEADER SIZE; 
payload > = new byte[payload_ size]; 











for {int 1 = HEADER SIZE; 1 < packet. size; i++) 
payload[i - HEADER SIZE] = packet[i]; 





// Interpret the changing fields of the header: 
PayloadType = header[1] & 127; 




















SequenceNumber = unsigned int (header[3]) + 256 * 
unsigned int (header [2]); 

Tamestamp = "unsigned int (header [7]) +256 * 
unsigned int (header[6]) + 65536 * 
unsigned: int (header [3] ).; + Ler772ie: * 
unsigned _ int (header [4]); 

} // end if 
} // end constructor 
[** 
* Get payload 
* 
* @param data - the data of the payload 
* 
* @€return the - the payload bistream of the RTPpacket 
and its size 
oe 
public int getpayload(byte[] data) { 
for. (ant a = 0p“ = payload -saize;> i++) 
data[i] = payload[i]; 


return (payload size); 


} // end getpayload() 


[** 
* Get length of the payload 


* 





* @return the length of the payload 
oa 
public..int..getpay load. léngthn{):. 4 


return (payload size); 
} // end getpayload_ length () 


[** 
* Get total length of the packet 


* 


* @return the length of the packet 
ef 
public int getlength() { 


return (payload _ size + HEADER SIZE); 





} // end getlength() 















































[** 
* Get the packet size 
* 
* @param packet the array of byte of the packet 
* 
* @return the total size of the packet 
a] 
public int getpacket (byte[] packet) { 
// Construct the packet = header + payload 
for (ime 1 = -O7 2. <“HEADER SIZE? i++) 
packet [i] = header[i]; 
for (int i = 0; i < payload_size; i++) 
packet[i + HEADER SIZE] = payload[i]; 








//return total size of the packet 
return (payload _ size + HEADER SIZE); 


} // end getpacket () 
[** 


* Get the timestamp 
* 








* @return the value of the timestamp 
ty 


public int gettimestamp() { 








return TimeStamp; 





} // end gettimestamp () 


[** 
* Get the sequence number 
* 





* @€return the sequence number 
ae | 
public int getsequencenumber() { 








return SequenceNumber; 





} // end getsequencenumber () 


[** 
* Getpayloadtype 


* 
* @return the payload type 
ig 

public int getpayloadtype() { 
return PayloadType; 


} // end getpayloadtype () 


* 


/ 


Check and return the proper unsigned number 


@param nb - an unsign bit 


+ + + * 


* @€return the unsigned value of 8-bit integer nb 
ad 


static int unsigned. 2ni (ant inb): 4 





if (nb >= 0) 
return (nb) ; 

else 
return (256 + nb); 





} // end unsigned int () 


} // end class RTPpacket 


[** 
* Title: API Development for Persistent Data Sessions 
Support 














* Description: Application server 
* Compiler : JBuilder 9 

* Author CPT.Chayutra Pailom THA 
* Date : January 20, 2005 

7 
import java.io.*; 
import java.net.*; 
import java.awt.*; 
import java.awt.event.*; 
import javax.swing.*; 
[** 


* This is the server of the project. This server is 
expected to coordinate 

* with one client at a time. It will create the thread as 
an ‘'agent' of the 

* server. This class is intended to use socket programming 
for both types of 

* protocols and graphic user interface on order to show 
the process. 














Expected number of clients which server can handle: 30 


@author CPT Chayutra Pailom THA 

/ 

public class Server extends JFrame implements 
ActionListener {f 


+ + + + 


De focore wie oral GUI for indicating server process --------- / 


/** JFrame of the server object */ 
public JFrame g, h; 


/** Lebel for showing the server process */ 
public JLabel label, label2; 





/** The area to show the process of the server */ 
private JTextArea textArea; 








/** The button to shutdown the visibility of the GUI */ 
private JButton buttonExit; 





aaa ole a Server socket, variables: “Hos ss=4-4—— if 


/** Server socket to be used to wait for the client 
connection */ 
private ServerSocket serverSocket; 


/** Socket to be used to send the TCP and RTSP request */ 
private Socket clientSocket; 





/** Array of server agent talking to the client */ 
private ServerThread clientThread[]; 








/** Number of created socket */ 
private int socketNumber; 





Input stream: tileers. =7 
private BufferedReader br; 


/** Output stream filters */ 
private BufferedWriter bw; 





/** Port to communicate with the server */ 
private int port; 





/** Buffer used to store the file content to send to the 
client */ 
private char[] buffer; 








/** Size of the file in bytes */ 
private int fileSize; 


jee File torbe.sent. to. the elrent.-*/ 
private String fileName; 





/** File input stream to be read */ 
private FileInputStream fis; 





J/** Status of the connection with the client */ 
private boolean connectionLost; 





/** Expected number of clients */ 
private int noOfClients; 








/** Sequence of client connected to the server */ 
private int clientNumber; 


[** 

* Default constructor 

* 

* @param name - file name to be retrieved 

* @param no - port number of the server to be connected 
af 


public Server(String name, int no) { 


// initialize variables 
fileName = name; 
port = no; 

connectionLost = 
clientNumber = 0; 
noOfClients = 0; 





false; 


// initialize agents 

clientThread = new ServerThread[30]; // can handle for 
30 threads 

//Socket[] clientSocket = new Socket[30]; 





// frame specifications 

Container container = getContentPane(); 
this.setTitle("Server Process"); 
this.setSize(500, 300); 
this.setLocation(0, 0); 











// buttons and textcomponents 

buttonExit = new JButton ("Exit") ; 
buttonExit.addActionListener (this); 

textArea = new JTextArea(); 
textArea.setEditable(false); 

JScrollPane scrollPane = new JScrollPane(textArea) ; 









































// border layout placements 
container.setLayout (new BorderLayout()); 
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container.add(scrollPane, "Center"); 
container.add(buttonExit, "South"); 











this.setVisible(true); // set visibiity of the main GUI 
boolean done = false; 


// GUI for TCP or UDP counter 
g = new JFrame(" UDP Counter"); 
h = new JFrame("TCP Counter"); 


// add window listener 
g.addWindowListener (new WindowAdapter() { 
public void windowClosing(WindowEvent e) { 
System.exit (0); 











} 
})3 
h.addWindowListener (new WindowAdapter() { 
public void windowClosing(WindowEvent e) { 
System.exit (0); 











} 
}); 





// initialize label 

















abel = new JLabel("Send frame # ", 
JLabel.CENTER) ; 

label2 = new JLabel("Send character # ay 
JLabel.CENTER) ; 





// frame attributes both TCP and UDP 
g.getContentPane().add(label, BorderLayout.CENTER) ; 
g.setSize(150, 50); 

g.setLocation(280, 50); 
h.getContentPane().add(label2, BorderLayout.CENTER) ; 
h 

h 











.setSize(300, 100); 
.setLocation(250, 50); 














// start the server 























ery at 
serverSocket = new ServerSocket (port) ; 
System.out.println("Binding to port : " + port + 
", please wait ..."); 

System.out.println("Server started : "+ 
serverSocket) ; 

System.out.println("Server IP : "+ 
serverSocket.getInetAddress()); 
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} 


readFile(fileName); // read the content of the file 


into buffer 
start(); // go start the server 


} 


catch (java.io.IOException ioe) { 


System.out.println("Cannot bind to port, 
using by another application "); 


} // end try - catch 


// end constructor 








/ | ~---------------------------------------- 
a 
// Public Methods: 
hd 
/ | ~---------------------------------------- 
[** 
* Set the logic of the communication status 
* 
* @param connectionLost - the status of the 
communication 
a 


port may be 


public void setConnectionLost (boolean connectionLost) { 


} 


this.connectionLost = connectionLost; 


// end setConnectionLost () 


[** 


* Listener for the exit button 


* 





* @param e - Listener for the GUI 
a | 


public void actionPerformed(ActionEvent e) 


} 





if (e.getSource().equals(buttonExit)) { 
System, ex1-.(00); 
} 


// end actionPerformed () 


{ 


[** 
* Add the text to the GUI panel 


* 





* @param message - message to be added on the panel 
as 
public void addTextArea(String message) { 








textArea.append (message) ; 
textArea.append("\n") ; 














} // end addTextArea () 





* Method to start the server 











private void startc). 4 








// do the iteration until it reach the maximum number 
of threads 
while (noOfClients < clientThread.length) { 





try { 


addTextArea ("Server is waiting for a client to 
establish the connection...\n"); 





// create the socket to communicate with the client 
clientSocket = serverSocket.accept (); 








addTextArea ("Server accepted") ; 
JOptionPane.showMessageDialog(this, "New connection 
is established!"); 





addThread(clientSocket, clientNumber); // create 
the thread for communication 


addTextArea ("Thread #" + (clientNumber + 1) +" 
created! \n"); 


if (clientNumber > 0) { 


LES 


clientThread[clientNumber - 
1].setConnectionLost (true) ; 
removeThread(clientNumber - 1); 








} // end if 
clientNumber++; // increment the number of socket 
} catch (java.io.IOException ioe) { 


System.out.println("Client acceptance error ==> "+ 
ioe.getMessage()); 





} catch (Exception e) { 





Ssystem.out..praintin(e.getMessage ()); 





} // end try - catch 
} // end while 
// inform the user when it reaches the maximum number 


of clients 
if (noOfClients == clientThread.length) { 





JOptionPane.showMessageDialog(this, "Server can't add 
anymore threads!"); 


} 


b+ J/ end: srart’-C 





k*k 
. Method to read the content of the file 
* 
* @param fileName - file to be read into buffer 
* 
cee void readFile(String fileName) { 
try { 
boolean fileExist = true; 
File file = new File(fileName) ; 
try { 
fis = new FileInputStream(fileName) ; 
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} catch (FileNotFoundException e) { 
fileExist = false; 
} // end try - catch 


if (fileExist) { 

















System.out.println("File " + fileName + " is 
found"); 

fileSize = (int) file.length(); // get the length 
of the file 

System.out.printlin("File Size is : " + fileSize + " 
bytes"); 


// declare the array of character to be kept for 
sending to the client 
buffer = new char[fileSize]; 


// buffer initialization 
FileReader fr = new FileReader (file); 
br = new BufferedReader (fr); 





br.read(butfer, 0, £i116Size)\> // read’ the file 
into buffer 


} else { 





System.out.println("file '" + fileName + "' can not 
be found"); 


for (int i= 0; i < fileSize; i++) { 





buffer[i] = (char) i; 
} Jf end. ror 
} // end if - else 
} catch (Exception e2) { 


System.out.printin("Problem in reading file" + e2 + 
WW) 


} // end try - catch 


} // end readFile() 





[** 

* Method to add the new connection as a thread 

* 

* @param socket - socket for TCP or RTSP communication 

* @param clientNumber - the sequence number of connected 
client 


* @throws Exception 
i 
private void addThread(Socket socket, int clientNumber) 
throws Exception { 





clientThread[clientNumber] = new ServerThread(this, 
socket, fileName, (clientNumber + 1)); 
open (socket); // open the streams 





// set important parameters 

clientThread[clientNumber].setParameters (br, bw, 
buffer, fileSize); 
clientThread[clientNumber].setConnectionLost (false); 


























clientThread[clientNumber].start(); // start the 
thread 


} // end thread 








[** 
* Method to remove the expired connection 
* 
* @param clientNumber - the sequence number of connected 
client 
*/ 
private void removeThread(int clientNumber) { 
ServerThread toTerminate = clientThread[clientNumber]; 
textArea.append("Removing thread# " + (clientNumber + 
1) + wernt yo 
try { 


//toTerminate.stop(); 
toTerminate.close(); 


} catch (IOException ioe) { 
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textArea.append("Error in closing thread\n"); 
} // end try - catch 


textArea.append("\nThread# " + (clientNumber + 1) + " 
removed! \n\n") ; 





} // end removeThread () 


[** 
* Method to open streams filters 
* 
* @param clientSocket - socket for the server - client 
communication 


* 


* @throws IOException 
Sf, 
private void open(Socket clientSocket) throws IOException 


{ 





br = new BufferedReader (new 
InputStreamReader (clientSocket.getInputStream())); 
bw = new BufferedWriter (new 
OutputStreamWriter (clientSocket.getOutputStream())); 











} // end open() 





public static void main(String arg[]) { 
try { 


Server server = new Server(arg[0], 
Integer.parselInt(arg[1])); 





} 


catch (NumberFormatException nfex) { 





System.out.println(nfex.getMessage()); 


} catch (ArrayIndexOutOfBoundsException aiobe) { 
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System.out.println("USage: Java Server 
<portnumber>\n") ; 


} catch (Exception e) { 


System.out.println(e.getMessage()); 








} // end try - catch 
bof /- end main 


} // -end. class: Server 
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[** 

* Title: API Development for Persistent Data Sessions 
Support 

Description: Server agent 

Compiler : JBuilder 9 

Author CPT.Chayutra Pailom THA 

Date : January 20, 2005 








+ + + * + 


-event.*; 


ke 
, 


ava.awt 
ava.net. 
ava.io.*; 

avax.swing.*; 














ae Ae eee ee 


a oe ee ee 
3 
'O 
O 
6 
qT (TT ¢T €T (CF CT CT 


mpor ava.util.*; 

mpor avax.swing.*; 
mpor avax.swing.Timer; 
[** 


* This class is expected to communicate with only one 
client per connection. 

* Tt acts as an ‘'agent' of the server. This class is 
intended to use socket 

* and important variables passed from the server for both 
types of protocols 

* and it uses graphic user interface on order to show the 
process. 

* 

* @author CPT Chayutra Pailom THA 

*/ 

public class ServerThread extends Thread implements 

Runnable { 








/** Socket to be used to send the TCP and RTSP request */ 
private Socket clientSocket; 


/** The main object of the execution */ 
private Server server; 








jx* Inpit stream filters. *~/ 
private BufferedReader br; 


/** Output stream filters */ 
private BufferedWriter bw; 





fee Status of the connection with the client. */ 
private boolean connectionLost; 
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/** The buffer for containing the text file content */ 
private char[] buffer; 


/** Size of the file in bytes */ 
private int fileSize; 


Jee File to be sent to the client */ 
private String fileName; 





/** Offset for retriving the data */ 
private int indexToReadFile; 





ju* Status of the. thread: */ 
public boolean dead; 


fx*® Client. number */ 
private int ID; 


/** Socket to be used to send and receive UDP packets */ 
private DatagramSocket RTPsocket; 


/** UDP packet containing the video frames */ 
private DatagramPacket senddp; 





fee - CALS LP address. 7 
private InetAddress ClientIPAddr; 





/** destination port for RTP packets (given by the RTSP 
Cientk) */ 
private ant: REP dest pork =)0y 





a ee ae VDOT Verlebles Ss Seesssaqeaesasnsse vA 


/** Tmage nb of the image currently transmitted */ 
private int imagenb; 





/** VideoStream object used to access video frames */ 
private VideoStream video; 





/** RTP payload type for MJPEG video */ 
p yp 
pravate static. int, MIPEG TYPE «= 267 


/** Frame period of the video to stream, in ms */ 
private static int FRAME PERIOD = 100; 
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/** Length of the video in frames */ 
private static int VIDEO LENGTH = 500; 





/** Timer used to send the images at VDO frame rate */ 
private Timer timer; 


/** Buffer used to store the images to send to client */ 
private byte[] buf; 





/** Sequence number of RTSP messages within session */ 
private int RTSPSeqNb; 


Jx* EnO..of command: */ 
private final static String CRLF = "\r\n"; 





/** rtsp states */ 

final static int INIT = 0; 
final static int READY = 1; 
final static int PLAYING = 
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/** rtsp message types */ 

final static int PLAY = 3; 
final static int PAUSE = 4; 
final static int CLOSE = 5; 























pu LOGuce: £Or- Iteration, conkrod -*/ 
private boolean done; 


[ /--------- n-ne 
ae 
py: Constructor: 
// 
/[ /----------n--o-o--- 
[** 
* Default constructor 
* 
* @param pServer - the server object 
* @param pSocket - socket for TCP or RTSP communication 
* @param fileName - file to be retrieved 
* @param threadID - ID of the thread 
* 
* @€throws Exception 
* 


™ 


public ServerThread(Server pServer, Socket pSocket, 
String fileName, int threadID) throws Exception { 
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// variable assignment 











server = pserver; 
clientSocket = pSocket; 
this.fileName = fileName; 
ID = threadID; 





// initialize variables 
dead = false; 

imagenb = 0; 

RTSPSeqNb = 0; 





// init timer 

TimerHandler timerListener = new TimerHandler(); 
timer = new Timer(FRAME PERIOD, server); 
timer.addActionListener (timerListener) ; 
timer.setInitialDelay (0); 


timer.setCoalesce (true); 














//allocate memory for the sending buffer 
buf = new byte[15000]; 


f/f end constructor 





[** 
* Method to execute the runnable object 
mf 

public void run() { 
try <{ 


// loop until the socket get closed 
while (!clientSocket.isClosed()) { 








//clientSocket.setSoTimeout (SOCKET TIMEOUT) ; 
System.out.println ( 
"In while loop and wait for the command..."); 





// get the request from the client - one request 
per session 

String text = new String (br.readLine()); 

System.out.println (text); 











if (text != null) { 
handle(text); // server activation 


bff send: at 
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// check for the-end of the: file 
if (((indexToReadFile) == buffer.length) || 
(i1magenb >= VIDEO LENGTH)) { 


try { 


close(); // close when done, another thread is 
waiting for new jobs 


} catch (java.io.IOException io) { 


System.out.println(io.getMessage()); 





} // end try - catch 
break; // quit inner loop 
} S/ end, 2f 
} // end while 


} catch (SocketTimeoutException stoe) { 





System.out.printin("SocketTimeoutException ==> " + 
stoe.getMessage()); 





} catch (SocketException se) { 


System.out.println("Socket Exception ==> " + 
se.getMessage()); 





try { 
close(); 
} catch (IOException ioe) {} 


} catch (IOException ioe) { 


— 


System.out.printiln("IOException ==> " + 
ioe.getMessage()); 








} catch (java.lang.NullPointerException npe) { 





System.out.println("NullPointerException ==> " + 
npe.getMessage()); 
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} 
/ 


t+ + + + + * F 


a 


} catch (Exception e) { 


System.out.println("Client acceptance error ==> 
e.getMessage() + e); 








} // end try - catch 

















System.out.printin("ConnectionLost status ==> " + 
connectionLost) ; 
System.out.println("Socket close? ==> "+ 


clientSocket.isClosed()); 
if (connectionLost == true) { 
server.setConnectionLost (true) ; 
hoff sen Ack 
dead = true; 


// end run() 


+ 


Method to assign parameters 


@param br - Input stream filters 

@param bw - Output stream filters 

@param buffer - array of characters 

@param fileSize - the size of the file in bytes 





public void setParameters (BufferedReader br, 


} 
/* 


* 
* 
* 
* 


public void setConnectionLost (boolean connectionLost 


BufferedWriter bw, char[] buffer, int fileSize) 
this.br = br; 
this.bw = bw; 
this.buffer = buffer; 
this.fileSize = fileSize; 








// end setParameters() 


* 


Method to send the character to the client 








@param connectionLost - the status of the connection 


/ 





~~ 
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this.connectionLost = connectionLost; 


} // end setConnectionLost () 


[** 


* Method to close the connection 
* 


* @throws IOException 
aoa 


public void close() throws IOException { 





if (clientSocket.isClosed() == false) { 
clientSocket.close(); 

Pog fend: ae 

if (br != null) { 
br.close(); 

IL F ene ar 

if (bw != null) { 
bw.close(); 

} // end if 


} // end close 


[** 
* Method to assign parameters 
* 
* @param input - the request string from the client 
Ail 
private void handle(String input) { 





// sending size 
Lf (inpuir, equale("/size™))-~ 4 


string size = Integer. tostring (buffer. length) ; 
System.out.println("Size : " + size + ""); 


send(size); 


} // end 4£ 
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//sending data 

















else 1f: (input sstartswith("/get ™)). -{ 
System.out.println("Receive command -->" + input); 
StringTokenizer st = new StringTokenizer (input) ; 
String[] commandArray = new String[2]; 
int counter = 0; 
// keep the indormation of the request in the array 
while (st.hasMoreTokens()) { 
commandArray[counter] = st.nextToken(); 
countertt; 


} // end while 


if (commandArray[0].equalsIgnoreCase("/get")) { 





// convert to number of the index file to be read - 
-> can be started at 0 or at the byte it lost 
indexToReadFile = 
Integer.parselInt (commandArray[1]); 


server.h.setVisible (true); 


while (((indexToReadFile) < buffer.length) && 
(connectionLost == false)) { 
try~ { 


// now array(file in bytes) has all bytes --> 
send each byte 
sendChar (buffer [indexToReadFile]); 


server.label2.setText ("Character # " + 
indexToReadFile +" , " + 
buffer [indexToReadFile] + " is sent"); 





} catch (Exception e) { 


System.out.println("While sending characters, 
Exception ==> " 4 .getMessage()); 








} // end try - catch 


indexToReadFilet+t+; // increment the index 
System.out.printin(indexToReadFile + ", " + 
buffer.length) ; 
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if (connectionLost == true) { 





System.out.println("Next indexToReadFile ==> " 
+ indexToReadFile) ; 








// break; //exit the while loop 
} // end if 
} // end while 
if (indexToReadFile == buffer.length) { 
JOptionPane.showMessageDialog(server, "End of 


File. Thread# " + ID + ™ done!"); 
server... Séecvisiblée(false).; 





b f/ end: Lt 


bff end a 





} else if (input.startsWith("/Setup")) { 


System.out.println("Receive command -->" + input); 
StringTokenizer st = new StringTokenizer (input) ; 
String[] commandArray = new String[3]; 

int counter = 0; 





// keep 
while (s 


he indormation of the request in the array 
-hasMoreTokens()) { 





ct ct 








commandArray[counter] = st.nextToken(); 
System.out.println(commandArray[counter]); 
countertt; 


} // end while 





RTSPSeqNb = Integer.parselInt (commandArray[1]); 
RIP- dest port = Integer. parse nt (commandArray (4) ) 3 








// do setup session automatically 
// init the VideoStream object: 
try { 








video = new VideoStream(fileName) ; 
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} catch (Exception e) { 


System.out.println("problem creating video stream" 
+ e); 


} // end try - catch 





// init RTP socket 
try { 


RTPsocket = new DatagramSocket (); 
} catch (Exception e) { 


System.out.printin("problem creating Datagram 
Socket" + e); 


} // end try - catch 





System.out.println("RTPsocket created!"); 


// Wait for the SETUP message from the client 
int request type; 
done = false; 





ClientIPAddr = clientSocket.getInetAddress(); 
System.out.println("ClientIPAddr = " + ClientIPAddr) ; 











server.g.setVisible (true) ; 
while (!done) { 


// parse the request 





request type = parse RTSP request(); // blocking 
if ( CeSsquest. type: ==) PLAY iy x4 
if (RTSPSeqNb == 0) { 


System.out.printlin("In else if 'PLAY' before 
start the timer"); 

















// start sending the video 
timer.start(); 





} else { 
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// skip to the point it lost the connection 


System.out.println("RTSP Sequence number = + 
RTSPSeqNb) ; 


// do the iteration, just reading - no sending 
for (int i = 0; i < RTSPSeqNb; itt) { 


try { 
imagenbtt+; 
System,out<printin(™ nin, for loop, discard 
frame# " + i); 


// get next frame to send from the video, 














as well as its size 
int image length = video.getnextframe (buf) ; 
System.out.println("image length = " + 
image length) ; 


// Builds an RTPpacket object containing the 
frame 
RTPpacket rtp packet = new 
RTPpacket (MJPEG TYPE, imagenb, imagenb * 
FRAME PERIOD, buf, 
image length) ; 


// get to total length of the full rtp 
packet to send 

int packet length = rtp packet.getlength(); 

System. Out, printin«” packet. length =" + 
packet. length); 











// retrieve the packet bitstream and store 
it in an array of bytes 

byte[] packet bits = new 
byte[packet length]; 

rtp packet.getpacket (packet_bits); 








} catch (Exception e) { 





System.out.printin(e.getMessage()); 





} // end try - catch 


} // end for 
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/** After reading the undesired VDO part, start 
to send the rest 
* of the video to the client */ 
timer.start(); // start timer 








} // end if - else 


} else if (request _ type == PAUSE) { 





System.out.printlin("In else if 'PAUSE'"); 
timer.stop(); // stop timer 





} else i (request. type. == CLOSE), 4 





System.out.printlin("In else if 'CLOSE'"); 
timer.stop();// stop timer 








done = true; 
//RTPsocket.close(); 
server.g.setVisible(false); 
} // end if - else if 
try { 


// End of File 
if (imagenb >= VIDEO LENGTH) { 


done = true; 
RTPsocket.close(); 


} // end if 
} catch (Exception e) { 


System.out.println("problem creating Datagram 
Socket" + e); 


} // end try - catch 
} // end while 
} // end else if "/Setup' 
} // end handle() 


oes 
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* Method to send the message to the client 


* 


* @param message - the string request 
a 


private void send(String message) { 
cEy 
bw.write (message) ; 
bw.newLine(); 
bw. flush (); 
} catch (IOException ioe) { 
server.addTextArea ("While sending command, 


IOException ==> " + ioe.getMessage()); 
} // end try - catch 





} //-end send () 


[** 


* Method to send the character to the client 
* 





* @param ch - the string request 
BY 


private void sendChar(char ch) { 
try { 
bw.write (ch); 
bw.newLine () ; 
bw. flush (); 
} catch (IOException ioe) { 
System.out.printin(this + "While sending characters, 


IOException ==> " + ioe.getMessage()); 
connectionLost = true; 








} catch (Exception e) { 


System.out.println(this + "While sending characters, 
Exception ==> " + e.getMessage()); 
connectionLost = true; 





} // end try - catch 
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} // end sendChar () 


[** 
* Method to parse the request from the client 


* 








* @return request type 
* / a 
private int parse RTSP request() { 
int: Fequest type. = ly 
try { 


//parse request line and extract the request type: 
String RequestLine = br.readLine(); 














System.out.println("RTSP Server - Received from 
Glrenti) 3 

System.out.println("Received command --> " + 
RequestLine) ; 

StringTokenizer tokens = new 





StringTokenizer (RequestLine) ; 
String request type string = tokens.nextToken(); 








if ( (new 
String (request type string) ) .compareTo ("PLAY") 
S= OR a 
request type = PLAY; 
SYSlLem,OUL. prin ind Reques™ Type: == ft 
PEGUSSL. EYPS)+; 





} else iff ( (new 
String (request type string) ) .compareTo ("PAUSE") 
== 0) f 


request type = PAUSE; 
System.out.printin("Request type --> " + 
request type) 7 


} else iff ( (new 
String (request type string) ).compareTo ("CLOSE") 
Se Oe 


request type = CLOSE; 
System.out.printin("Request type --> " + 
request_type); 
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ff end SF <a: Tt 
} catch (Exception ex) { 


System.out.println("Exception caught: " + ex); 
System.exit (0); 





Vy end: try = eaceh 
return (request type); 


} // end parse RTSP_ request () 


[** 


* Method to send the response to the client 


Bes 

















private void send RTSP_response() { 
try { 
System.out.printin("EOF sent!"); 
// write the message to the server using buffer 
writer 
bw.write ("EOF"); 
bw.flush(); 


} catch (Exception ex) { 





System.out.println("in send Exception caught: " 
ex); 
System.exit (0); 
} // end try - catch 
} // send_RTSP_response() 

| | -------------- INNER CLAS § --------------- // 
| | ~---------------------------------------------- 
// 
// Action Listener Methods: 
hd 
| | ~---------------------------------------------- 


13:5 


+ 


private class TimerHandler extends JFrame implements 
ActionListener {f 


public void actionPerformed(ActionEvent e) { 
System.out.printin("\nIn the timer"); 
// if the current image nb is less than the length of 


the video 
if (imagenb < VIDEO LENGTH) { 





imagenbt++;// update current imagenb 
try { 


// get next frame to send from the video, as well 
as its size 

int image length = video.getnextframe (buf) ; 

System.out.println("image length = " + 
image length) ; 








// Builds an RTPpacket object containing the 
frame 
RTPpacket rtp packet = new RTPpacket (MJPEG TYPE, 
imagenb, imagenb * FRAME PERIOD, buf, 
image length) ; 





// get to total length of the full RTP packet to 








send 
int packet length = rtp packet.getlength(); 
Ssystem.out..printin("packet. length = ™ + 


packét. lLength).; 





// vetrieve the packet bitstream and store it in 

an array of bytes 
byte[] packet bits = new byte[packet length]; 
rtp packet.getpacket (packet_bits); 








// send the packet as a DatagramPacket over th 
UDP socket 
senddp = new DatagramPacket (packet bits, 
packet length, ClientIPAddr, RTP_dest_ port); 
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// test the connection by using get command 
if (connectionLost == false) { 


//Thread.sleep(500); // make it longer 
RTPsocket.send(senddp) ; 


// update GUI 





server.label.setText ("Send frame # " + imagenb 
+ "\n") : 
System.out.printin("Send frame # " + imagenb); 
} else { 


System.out.printin("\nPhysical connection is 

lost. for thread# i." 4+ ID); 

System.out.printin("\nThe timer will be stop 
and wait for another request from the 
client! \n"); 




















// stop the timer 

timer.stop(); 

server.g.setVisible(false); // disable the 
visibility of the GUI 





}. f/ end tf =-else 
} catch (Exception ex) { 


In("Exception in the timer"); 
In("Exception caught: " + ex); 


-prin 
-print 


System. out 
System. out 














CT CT 
CT GT 





System.exit (0); 
} // end try - catch 
} else { 


// if we have reached th nd of the video file, 
stop the timer 

timer.stop(); 

System.out.println("The end of the video!"); 





try { 
send RTSP response:() ; 


int reply = parse RTsP request ().; 
13-2 


if (reply == CLOSE) { 
done = true; 
//RTPsocket.close(); 
server.g.setVisible (false); 

bff ene See 

} catch (Exception exp) {} 
} // end if - else 
} // end actionPerformed () 


} // end inner class timerListener 


} // end class ServerThread 
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[** 

* Title: API Development for Persistent Data Sessions 
Support 

Description: Streaming Video with RTSP and RTP 

Compiler : JBuilder 9 

Author CPT.Chayutra Pailom THA 

Date : January 20, 2005 








+ + ee 


is 
import java.io.*; 


public class VideoStream { 


PRE Video fa Le */f 
FileInputStream fis; 





/** current frame nb */ 
int frame_nb; 


public VideoStream(String filename) throws Exception{ 
//init variables 
fis = new FilelInputStream(filename) ; 
frame nb = 0; 


} // end constructor 


/ 


Get the next frame 


@param frame array of byte of the video 


+ +  * 4 


@return the next frame as an array of byte and the 
size of the frame 
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* @throws Exception 
ty, 

public int getnextframe(byte[] frame) throws Exception { 
int length = 0; 


String length_string; 
byte[] frame_length = new byte[5]; 





// Read current frame length 
fis.read(frame length,0,5); 


// Transform frame length to integer 
length string = new String(frame_ length) ; 
length =-Integer.parseInt {length string); 








return (fis.read(frame,0,length) ); 
} // end getnextframe () 


// end class VideoStream 


APPENDIX B. CLASS DIAGRAMS 


In this section, 


are shown in order 


el 





aeee2e 


ass 


Lass 
Lass 
Lass 
Lass 


lass 


diagram 
diagram 
diagram 
diagram 


diagram 





diagram 


as 
of 
of 
of 
of 
of 


of 


the 


class diagrams from Chapter IV 


following: 


the 
the 
the 


the 


the 








the 


application client 





persistency API 
RTP packet 


application server 








application proxy server 


streaming video for RTP and RTSP 





Figure 40. Class diagram of the application client 
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Figure 41. Class diagram of the persistency API 
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Client.timerListener ServerThread.TimerHandler 














& CC: int 
@ Extension : int 

@ header : byte] 

@ Marker: int 

@ Padding : int 

@ payload : bytef] 

@ payload_size : int 

@& PayloadType : int 

@ SequenceNumber : int 
¢ Ssrc: int 

@ TitneStamp : int 
Version : int 
HEADER_SIZE : int 


® getlenath() ; int 

® getpacket() : int 

®© getpayload() ; int 

© getpayload_length() : int 
© getpayloadtype() : int 

® getsequencenumber() : int 


®© gettimestampd) : int 
® printheader() : void 
& RTPpacket() : void 
> RTPpacket() ; void 
=f unsigned_intQ : int 


Figure 42. Class diagram of the RTP packet 
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Figure 43. Class diagram of the application server 
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Figure 44. Class diagram of the application proxy server 
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_— ServerThread.TimerHandler 








®% getnextframed) : int 
% VideoStream() : void 


Figure 45. Class diagram of the streaming video for RTP and RTSP 
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